Разница между статическими и разделяемыми библиотеками?
=======================================================

В чем разница между статическими и разделяемыми библиотеками?

Я использую Eclipse и существует несколько типов проектов, включая Static Libraries и Shared Libraries? Имеет ли преимущество преимущество над другим?

 

Общие библиотеки - файлы .so(или в Windows.dll, или в OS X.dylib). Весь код, связанный с библиотекой, находится в этом файле, и на него ссылаются программы, использующие его во время выполнения. Программа, использующая общую библиотеку, ссылается только на код, который он использует в общей библиотеке.

Статическими библиотеками являются .a(или в Windows.lib) файлы. Весь код, связанный с библиотекой, находится в этом файле, и он напрямую связан с программой во время компиляции. Программа, использующая статическую библиотеку, берет копии кода, который он использует из статической библиотеки, и делает ее частью программы. [У Windows также есть .lib файлы, которые используются для ссылки .dll файлов, но они действуют так же, как и первый.]

В каждом методе есть преимущества и недостатки.

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

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

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

 

Статическая библиотека похожа на книжный магазин, а разделяемая библиотека похожа на... библиотеку. С первым вы получаете свою собственную копию книги/функции, чтобы забрать домой; с последним вы и все остальные ходите в библиотеку, чтобы использовать ту же книгу/функцию. Поэтому любой, кто хочет использовать (общую) библиотеку, должен знать, где это, потому что вам нужно "пойти" на книгу/функцию. С помощью статической библиотеки книга/функция принадлежит вам, и вы держите ее в своем доме/программе, и как только вы ее получите, вам все равно, где и когда вы ее получили.

 

Упрощенная:

* Статическое связывание: один большой исполняемый файл
* Динамическое связывание: небольшой исполняемый файл плюс один или несколько файлов библиотек (DLL файлы в Windows,.so на Linux или .dylib на macOS)

 

Статические библиотеки скомпилированы как часть приложения, а разделяемые библиотеки - нет. Когда вы распространяете приложение, которое зависит от общих библиотек, библиотеки, например. dll на MS Windows.

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

Помимо использования небольших приложений, общие библиотеки предлагают пользователю возможность использовать свою собственную, возможно, лучшую версию библиотек, а не полагаться на одну часть приложения

 

Для статической библиотеки код извлекается из библиотеки компоновщиком и используется для создания окончательного исполняемого файла в момент, когда вы компилируете/создаете приложение. Окончательный исполняемый файл не имеет зависимости от библиотеки во время выполнения

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

Сам язык программирования C не имеет понятия ни статических, ни общих библиотек - они полностью являются функциями реализации.

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

 

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

OTOH, преимущество статических библиотек в том, что все включено в ваше приложение. Поэтому вам не нужно беспокоиться о том, что у клиента будет доступная библиотека (и версия) в их системе.

 

В дополнение ко всем остальным ответам, одна вещь, о которой еще не упоминалось, является развязкой:

Позвольте мне рассказать о реальном производственном коде, который я имел в виду:

Очень большое программное обеспечение, состоящее из > 300 проектов (с визуальной студией), в основном создаётся как статическая библиотека и, наконец, все связаны друг с другом в одном огромном исполняемом файле, вы получаете следующие проблемы:

-Личное время очень велико. Вы можете получить более 15 минут ссылки, так как 10 секунд времени компиляции
-Некоторые инструменты находятся на колене с таким большим исполняемым файлом, как инструменты проверки памяти, которые должны обрабатывать код. Вы можете попасть в пределы пределов, которые были замечены как дураки.

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

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