Преимущества реализации интерфейса перед связыванием с библиотекой

Я хочу написать программу на C++, которая воспроизводит MP3. Среди доступных MP3-декодирующих библиотек я выбрал mpg123.Преимущества реализации интерфейса перед связыванием с библиотекой

Я заметил, что, помимо возможности связывания с libmpg123 и выполнения необходимых вызовов функций в моем коде, библиотека включает в себя интерфейсный/интерфейсный интерфейс, который позволяет мне общаться с его исполняемым файлом и, таким образом, не иметь включить его код в мою программу.

В чем преимущества написания интерфейса, а не просто ссылки на библиотеку?

источник

2010-09-03 Lawand

В более общем случае можно сделать это по причинам лицензирования. В этом случае это не имеет смысла. Bcause libmpg123 лицензируется LGPL. –

Лицензирование MPEG Layer3 может быть другой причиной. Некоторые разработчики могут захотеть исключить возможность того, что их программное обеспечение будет включать в себя любую потенциально запатентованную технологию. Использование front-end позволяет избежать этого, позволяя программному обеспечению распределяться на 100% независимо от исходного. И пользователи имеют возможность самостоятельно загружать и устанавливать серверные. – Dummy00001

Большинство из преимуществ происходит от разделения процесса между исполняемым файлом и библиотекой исполняемого файла:

Повышение безопасности & безопасности: если библиотека сбой, это не приведет к сбою приложения.
Неявная многопроцессорная обработка: поскольку обе работают на отдельных процессах, это почти бесплатно.
Предрасположение к сетям: если связь между процессами выполняется с помощью труб или stdin/stdout, вы можете легко переслать их в сокеты и запустить исполняемый файл на отдельной машине.
Язык нейтральный: вы можете использовать любой язык программирования, который вы хотите.

Конечно, есть штраф за исполнение при использовании внешнего канала связи. Но преимущества такого развязки могут быть весьма впечатляющими.

источник

2010-09-03 20:13:04

+1, но «Повышенная безопасность»? Если библиотека сбой и выполняется как отдельный процесс, это может быть очень плохой конец с длинным потоком на bugtraq. – doc

Насколько я могу судить, единственное использование исполняемого файла было бы для целей тестирования. Вы запустили эту стороннюю библиотеку как исполняемый файл, чтобы понять поведение различных API-интерфейсов, чтобы вы могли лучше понять его использование из своего кода и посмотреть, как они работают с различными входами. После этого вы привяжете его к вашему процессу, чтобы вызовы библиотеки находились в адресном пространстве вашего процесса. Если вы просто запускаете 2 исполняемых файла одновременно, у вас также будет накладные расходы IPC.

источник

2010-09-03 20:12:42 Cratylus

Можете ли вы рассказать о «накладных расходах IPC»? – Lawand

Если у вас есть два процесса обмена данными друг с другом, каждый процесс работает в своем собственном адресном пространстве. Чтобы общаться друг с другом, вы должны использовать средства Inter Process Communication. В зависимости от вашей цели эффективности эти издержки (для связи через примитивы IPC) могут представлять интерес, поскольку производительность не будет такой же, как при вызове API в вашем собственном адресном пространстве. – Cratylus

Вы можете обновить бэкэнд без перекомпиляции своей программы.
Если бэкэнд выходит из строя, он, вероятно, не использует вашу программу.

источник

2010-09-03 20:17:02

Объявление 1. Это также может быть сделано с общей библиотекой, если только ABI не изменяется. Если интерфейс нуждается в изменении, он должен быть изменен в beckend так же, как и в библиотеке. Так что в этом нет никакой пользы. – doc

Преимущества реализации интерфейса перед связыванием с библиотекой

ответ

Смежные вопросы