Каковы варианты использования статических библиотек в C++? Я видел, что люди создают библиотеки DLL или некоторые, которые используют только статические библиотеки. Какая у вас рекомендация?Где я должен использовать статическую библиотеку в C++
Я большой поклонник статических библиотек почти везде. Одна большая вещь, которую DLL вы получаете, что статические библиотеки не могут сделать, - это возможность динамически загружать и выгружать библиотечные функции. Поэтому, если ваше приложение будет поддерживать какие-то плагины с горячей заменой, вам нужно использовать динамические библиотеки. В противном случае вы, вероятно, можете использовать статические библиотеки.
Статические библиотеки открывают двери для множества оптимизаций, которые вы не можете сделать с динамическими библиотеками, потому что они выполняются во время ссылки. В мире Microsoft Outlook Time Code Generation (LTCG) дает вам возможность выполнять целую оптимизацию программы и удалять незавершенные коды не только с вашим приложением, но и с вашими библиотеками (в gcc это называется Оптимизация времени связи [LTO])
Кроме того, статические библиотеки, как правило, делают вашу программу более простой для распространения, потому что вы не вынуждены проходить через множество файлов библиотеки, и вы можете полностью избежать DLL-ад, если бы вы когда-либо продавали свою библиотеку.
Преимущество в том, что вам не нужно перекомпилировать всю программу, если вы внесете изменения в динамически связанную библиотеку. @Chris делает хороший аргумент в отношении dll-hell, но если это незначительная ошибка, которая не влияет на API, это может сэкономить вам перекомпиляцию.
Существует сообщение SO, в котором говорится о том, что Windows не может применять обновления к вашей программе, если вы статически связываете свои библиотеки (ссылка на них). Хотя я думаю, что вы больше говорите о статической привязке своих собственных модулей.
Почему изменение в статической библиотеке заставляет вас перекомпилировать всю программу, если интерфейс библиотеки не изменился? Я использую статические библиотеки все время, и только определенные модули, которые я касаюсь, перекомпилируются (если я не касаюсь интерфейса или встроенных функций, то есть). –
О, я вижу, откуда вы. Вы имели в виду, что если вы измените общую библиотеку (без касания интерфейса), вам не нужно повторно связывать и передислоцировать основной исполняемый файл. Согласен. Но вы прозвучали так, будто прикосновение к статической библиотеке приводило к перекомпиляции всех основных исполняемых исходных файлов, и это не так (опять же, если не менять интерфейс). –
ahh, извините за неясное. –
Ну Static DLL будет для хранения больших библиотек, а также для использования Multi-Os Куда, как я хотел бы назвать его так, что он способен быть побежали на Linux, Windows ...
Вы должны использовать общие библиотеки (DLL), если у вас есть значительная функциональность, которая должна быть разделена между приложениями; И эта функциональность может быть улучшена независимо от всех приложений и обновлений, отправленных отдельно.
«И» часть сложнее всего выполнить: обычно вы отправляете свое приложение с добавленной новой функциональностью и никогда не обновляете библиотеку, не обновляя приложение одновременно (я не говорю, что этого никогда не произойдет), но обычно два корабля в замке.
В противном случае проще создать обычные библиотеки и отправить заявку.
Пример хорошего (я использую этот термин свободно для примера) - это DirectX. Когда отправляется новая версия DirectX (и интерфейс не изменился), вам просто нужно обновить DLL и все приложения, которые используют DirectX, получают выгоду от новой версии библиотеки. На самом деле это не совсем так просто, но вы получаете эту идею.
Я использую статические библиотеки для реализации концепции пакета «UML». Все модули, принадлежащие к пакету, попадают в их собственный подкаталог, и я создаю подпроект IDE или makefile для этого каталога, который создает файл статической библиотеки * .a. Современные IDE позволяют работать с вашим пакетом верхнего уровня вместе с подпакетами в одном и том же «рабочем пространстве».
Если пакет (или группу пакетов) можно развернуть отдельно от основного исполняемого файла, тогда я скомпилирую его в общую библиотеку (* .so или * .dll) и рассмотрю ее как «компонент» в UML жаргон.
Это немного запутывает, выясняя, какие сущности сопоставляются с концепциями пакетов, компонентов и подсистем UML. –
В общем, хотя всегда есть исключения из этого правила, я бы сказал:
Преимущества библиотек DLL
Преимущество статических библиотек
Используйте статическую версию своих библиотек, где можете. Используйте динамические библиотеки, где вам нужно (лицензия, доступность или система плагинов).
Да, это. DLL - это дополнительное усложнение, дополнительные правила, меньшая совместимость с кросс-платформой и дополнительные проблемы с безопасностью. Вы, как разработчик приложений, редко хотите выгрузить lib или по-настоящему поделиться им с другими приложениями. –
Но тогда вы получите 20 исполняемых файлов, которые имеют тот же самый 500kb lib embedded - 10 МБ впустую пространства! –
Я бы предпочел пожертвовать 10 МБ пространства на жестком диске (что дешево), чем когда-либо иметь дело с файлами DLL-ада или Microsoft SxS. Я потратил больше часов на отладку сумасшедших ошибок загрузки DLL, чем потребовалось бы, чтобы заработать достаточно денег на дополнительном 10 МБ дискового пространства по ставкам 1989 года. – Beanz
Правда. Я немного лицемер, потому что я сам делаю то же самое, когда толчок приходит в себя. (Think Visual C runtime!) –