Статическое / динамическое связывание во время выполнения

Question

Каковы лучшие методы выбора метода связывания в VC ++? Может ли что-нибудь / все быть статически связано?

В динамически связанном проекте важно ли относительное / абсолютное расположение связанной библиотеки?

Какие плюсы и минусы?

добавлено : Я в основном имел в виду файлы lib. Они ведут себя так же, как ссылки dll?

Answer 1

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

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

Использование библиотек DLL также может помочь вам уменьшить объем используемой памяти, поскольку фактически вы загружаете библиотеки только тогда, когда они вам нужны, и вы можете выгружать их, когда закончите (подумайте, плагины приложений, загружайте библиотеку просмотра изображений только при открытом изображении и др.)

РЕДАКТИРОВАТЬ: Роберт Гэмбл добавил комментарий, который я пропустил: DLL загружаются в память, разделяемую всеми процессами в операционных системах. Это означает, что если две программы (или два экземпляра вашей программы) используют одну и ту же DLL, они будут использовать одну и ту же DLL, загруженную в память, что еще больше сократит общее использование памяти.

Answer 2

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

Хотя верно, что библиотеки DLL в основном устанавливаются / копируются в ту же папку, что и файл .exe, необходимо придерживаться правил загрузки загрузчиков (которые включают системную папку (плохая идея), PATH, текущий каталог [см. LoadLibrary API Справочная документация для полного описания приоритета]).

Вы "добавили" комментарий относительно файлов LIB. В ОБА динамических и статических, вы связываете, используя файлы LIB. Но в случае динамической загрузки вы поставляете .exe вместе со всеми зависимыми DLL (файлы LIB содержат экспортированные точки входа для соответствующей DLL).

Я предпочитаю DLL, так как мои приложения имеют тенденцию быть большими и сегментированными, и это позволяет мне поставлять ТОЛЬКО эти обновленные компоненты (DLL). Мы даже отделяем бизнес-логику от представления в своих собственных DLL [позволяет локализовать dll только для ресурсов независимо от логики.

Программирование с использованием библиотек DLL заставляет вас придерживаться контракта экспортируемого класса / метода или функции.

Answer 3

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

Если не выполнить тщательное обновление DLL, это может привести к проблемам, известным как DLL Hell .

В реальной жизни приложения склонны помещать все библиотеки, которые они используют, в один каталог с исполняемым файлом. Это позволяет обновить, но не способствует совместному использованию. Обновление состоит из обновления наборов DLL в каталоге приложения синхронно с DLL в центральном хранилище Windows.