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

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

Ответ 1

Есть несколько недостатков:

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

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

Ответ 2

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

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

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

Похоже на то, что верхняя часть перевешивает нижние стороны.

Ответ 3

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

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

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

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

Ответ 4

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

Ответ 5

Нет, ничего нового на этом фронте. Держите его таким образом.

Ответ 6

Наиболее определенно.

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

Мой вывод: либо выделение экрана, либо освобождение из клиентского кода, либо динамическая привязка ЭЛТ.

Ответ 7

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