При использовании динамического связывания вы фактически создаете [как минимум] два двоичных файла: программу как таковую (.exe) и dll. Для exe компилятор / компоновщик может обнаруживать неиспользуемые части кода и производить только минимальное необходимое в выводе. Однако в случае DLL все функции и переменные, помеченные как экспортированные (и весь код, необходимый для их работы), должны быть включены в выходной файл. Это потому, что компилятор / компоновщик не может знать, какие из этих функций могут использоваться программами (некоторые из них будут написаны в будущем ...).
Однако, поскольку вы, вероятно, будете писать как exe, так и dll (и), вы можете выбрать, что будет экспортироваться, и, следовательно, включать только минимально необходимое.
РЕДАКТИРОВАТЬ : в защите от чтения я отметил, что на самом деле вы рассматриваете возможность использования библиотеки с открытым исходным кодом, поэтому приведенное выше утверждение требует некоторой квалификации.
Если вы создаете открытый исходный код как есть (при условии, что источники включают сборку для DLL), он, вероятно, будет включать все публично объявленные функции библиотеки. Однако вы можете изменить список методов, объявленных для экспорта, и, следовательно, получить минимально возможное количество двоичных файлов.
Использование динамического связывания может привести к экономии общего количества необходимого двоичного файла , поскольку несколько программ могут использовать одну и ту же dll. Например, приложение для построения графиков и программа для видеоигр могут использовать одни и те же графические утилиты dll.
В целом, выбор использования динамического линкования или нет, не столь критичен . Эта проблема больше была проблемой в прошлом, с более медленным процессором (следовательно, более длительным временем сборки) и другими ограничениями, касающимися памяти, жесткого диска, а также пропускной способности распределения (с дискетами! И тому подобным ...).
Современное эмпирическое правило, в наши дни и в эпоху гигабайтного хранилища, выбирает статическую связь по умолчанию , если применяется одно из следующих значений:
- библиотека DLL является сторонней общедоступной библиотекой DLL (то есть, которую конечные пользователи могут обновлять независимо от вашего собственного цикла обновления)
- Некоторые части приложения, как правило, не используются, и базовая логика может быть «уложена» в DLL, что приводит к уменьшению общего объема времени выполнения (когда пользователи не используют базовые специализированные / расширенные функции). .
- программа является частью набора программ, некоторые из которых имеют достаточно общих возможностей, которыми можно поделиться.
- желательно иметь несколько версий приложения. Например, вы можете реализовать базовую / бесплатную / ограниченную версию приложения и полнофункциональную. Предполагая, что программе удастся вызвать любую версию функций с одним и тем же API, отдельные варианты поведения могут быть инкапсулированы только в DLL, что позволяет платящим пользователям просто загрузить «Premium DLL» и просто заменить другую (без установки). требуется).
- программное обеспечение является бета-версией, и ожидается, что конечный пользователь (и) отправит несколько ревизий. (как и выше, подкачка dll вместо переустановки - это хорошо).
- разные части приложения написаны на разных языках. В этом случае часто можно использовать статическое связывание (вынуждая компиляторы согласовывать соглашения о вызовах и тому подобное), но подход DLL также может облегчить это сотрудничество.
- Программное обеспечение производится разными программистами / командами. DLL обеспечивает неявное разграничение обязанностей.
Может быть еще несколько случаев, но, опять же, если нет какой-то существующей потребности в DLL, статическое связывание так же хорошо.