Статическое или динамическое связывание CRT, MFC, ATL и т. Д.

Question

В 90-е годы, когда я только начал работать с MFC, я использовал для динамического связывания своих приложений и отправлял соответствующие библиотеки MFC. Это вызвало у меня несколько проблем (DLL, черт возьми!), И я вместо этого переключился на статическое связывание - не только для MFC, но и для CRT и ATL. Кроме больших EXE-файлов, статические ссылки никогда не вызывали у меня никаких проблем - есть ли минусы, с которыми сталкивались другие люди? Есть ли веская причина для повторного пересмотра динамических ссылок? Мои приложения в основном STL / Boost в настоящее время FWIW.

Answer 1

Большинство ответов, которые я слышу об этом, касаются обмена вашими dll с другими программами или обновления этих dll без необходимости исправления вашего программного обеспечения.

Честно говоря, я считаю, что это минусы, а не минусы. Когда сторонний dll обновлен, он может измениться достаточно, чтобы сломать ваше программное обеспечение. И в наши дни, место на жестком диске не так ценно, как это было раньше, дополнительные 500 КБ в вашем исполняемом файле? Какая разница?

• Быть на 100% уверенным в версии dll, используемой вашим программным обеспечением, - это хорошо.
• Быть на 100% уверенным, что у клиента не будет головной боли от зависимостей, - это хорошо.

На мой взгляд, недостатки намного перевешивают недостатки

Answer 2

Есть некоторые недостатки:

• Большой размер exe (особенно если вы отправляете несколько exe)
• Проблемы с использованием других библиотек DLL, которые полагаются или предполагают динамическое связывание (например: библиотеки сторонних производителей, которые вы не можете получить в качестве статических библиотек)
• Различные c-runtime между DLL с независимой статической связью (без межмодульного выделения / освобождения)
• Нет автоматического обслуживания общих компонентов (нет возможности заставить сторонний поставщик модулей обновлять свой код для устранения проблем без перекомпиляции и обновления вашего приложения)

Мы делаем статическое связывание для наших приложений Windows, прежде всего потому, что оно позволяет развертывание xcopy, что просто невозможно при установке или использовании библиотек DLL SxS таким способом, который работает, так как процесс и механизм плохо документированы или легко могут быть удалены. Если вы используете локальные библиотеки DLL в каталоге установки, это будет работать, но не очень хорошо поддерживается. Неспособность легко выполнить удаленную установку без прохождения MSI в удаленной системе является основной причиной того, что мы не используем динамическое связывание, но (как вы указали) есть много других преимуществ для статического связывания. Есть плюсы и минусы для каждого; надеюсь, это поможет перечислить их.

Answer 3

До тех пор, пока вы ограничиваете использование определенных библиотек и не используете никаких библиотек DLL, вы должны быть хорошими.

К сожалению, есть некоторые библиотеки, которые вы не можете связать статически. Лучший пример, который у меня есть, - OpenMP. Если вы используете поддержку OpenMP в Visual Studio, вам необходимо убедиться, что установлена ​​среда выполнения (в данном случае vcomp.dll).

Если вы используете DLL, то вы не можете передавать некоторые предметы туда-сюда без серьезной гимнастики. std :: строки приходят на ум. Если ваши exe и dll динамически связаны, то распределение происходит в CRT. В противном случае ваша программа может попытаться выделить строку с одной стороны и освободить ее с другой. Плохие вещи ...

Тем не менее, я все еще статически связываю свои exe и dll's. Это значительно снижает вариабельность в установке, и я считаю, что это стоит некоторых ограничений.

Answer 4

Хорошей особенностью использования DLL является то, что если несколько процессоров загружают одну и ту же DLL, ее код может быть разделен между ними. Это может сэкономить память и сократить время загрузки приложения, загружающего DLL, которая уже используется другой программой.

Answer 5

Существуют некоторые лицензии на программное обеспечение, такие как LGPL, которые требуют, чтобы вы либо использовали DLL, либо распространяли свое приложение в виде объектных файлов, которые пользователь может связать вместе. Если вы используете такую ​​библиотеку, вы, вероятно, захотите использовать ее в качестве DLL.

Answer 6

Определенно.

Распределение выполняется в «статической» куче. Поскольку выделение освобождения должно выполняться в одной и той же куче, это означает, что если вы отправляете библиотеку, вам следует позаботиться о том, чтобы клиентский код не мог вызвать «ваш» p = new LibClass(), и удалить сам этот объект, используя delete p;.

Мой вывод: либо защитить выделение и освобождение от клиентского кода, либо динамически связать CRT.

Answer 7

Нет, ничего нового на этом фронте. Так держать.