Разница между статическими и общими библиотеками?

Question

Разница между статическими и общими библиотеками?

451

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

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

Mohit Deshpande 15 апр. 2010, в 22:48

Источник

4

В Википедии есть хорошее описание различия между статическими, динамическими и общими библиотеками.
Adam Holmberg 15 апр. 2010, в 22:13

Теги:

c++

c

static-libraries

shared-libraries

7 ответов

340

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

Paul Richter 16 апр. 2010, в 02:18

48

Упрощенная:

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

StackedCrooked 15 апр. 2010, в 22:21

1

Этот ответ является лучшим для меня, потому что это практично. Это имеет гораздо больше смысла, чем метафора, которая не говорит о том, что на самом деле происходит в компьютере. Зная, что это то, что происходит, я интуитивно знаю все другие последствия.
off99555 17 авг. 2018, в 09:24

26

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

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

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

Tarski 15 апр. 2010, в 23:16

3

DLL ад, как это было известно
gheese 01 нояб. 2013, в 15:45
1

«Статические библиотеки скомпилированы как часть приложения» ... статические библиотеки скомпилированы как статические библиотеки и связаны как часть приложения
user463035818 12 июль 2017, в 10:23

23

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

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

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

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

anon 15 апр. 2010, в 23:43

4

+1 за «Сам язык программирования C не имеет понятия ни о статических, ни о разделяемых библиотеках - они полностью реализованы».
Tiger 08 март 2016, в 14:22

14

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

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

Jasmeet 15 апр. 2010, в 22:40

1

исполняемый образ больше на диске, а также в памяти при использовании статических библиотек.
JustJeff 15 апр. 2010, в 22:19
0

Это правильно, это то, на что я ссылался, когда говорил, что все включено в ваше приложение.
Jasmeet 15 апр. 2010, в 22:40
0

Кроме того, файлы .so в системах * nix являются своего рода общей (динамической) библиотекой.
snr 20 фев. 2019, в 12:20

Показать ещё 1 комментарий

2

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

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

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

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

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

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

sandwood 30 окт. 2017, в 15:13

Ещё вопросы

В Википедии есть хорошее описание различия между статическими, динамическими и общими библиотеками.
Этот ответ является лучшим для меня, потому что это практично. Это имеет гораздо больше смысла, чем метафора, которая не говорит о том, что на самом деле происходит в компьютере. Зная, что это то, что происходит, я интуитивно знаю все другие последствия.
«Статические библиотеки скомпилированы как часть приложения» ... статические библиотеки скомпилированы как статические библиотеки и связаны как часть приложения
+1 за «Сам язык программирования C не имеет понятия ни о статических, ни о разделяемых библиотеках - они полностью реализованы».
исполняемый образ больше на диске, а также в памяти при использовании статических библиотек.
Это правильно, это то, на что я ссылался, когда говорил, что все включено в ваше приложение.
Кроме того, файлы .so в системах * nix являются своего рода общей (динамической) библиотекой.

Petesh · Accepted Answer · 2010-04-15T22-47-00.000Z

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

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

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

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

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

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

«заменить совместно используемый объект ... функционально эквивалентным, но может [улучшить] производительность»: в частности, эквивалентными функциональными возможностями, обращенными к вызывающей стороне, в семантическом использовании API (интерфейс прикладного программирования: сигнатуры функций и переменные, включая типы), но на стороне реализации функциональность может отличаться не только от перф .: например, функция всегда записывает в файл -> также регистрируется на TCP-сервере: ожидается порт в $ MY_APP_LOG_SERVER.
«[.SOS несут] небольшую дополнительную плату за выполнение функций» - это возможно (если группы функций / порядок были оптимизированы для размещения кэша в статической ссылке или из-за странностей в ОС / загрузчике / компиляторе / архитектуре, таких как cross -segment / Large-указатель перф. штрафов), но во многих архитектурах / настройках компилятора динамический компоновщик исправляет вызов, чтобы создать точно такие же коды операций вызывающей машины.
«Поскольку код подключен во время компиляции, никаких дополнительных затрат на загрузку во время выполнения не возникает. Код просто есть». - да и нет ... это все в исполняемом образе, готовом для вставки, если требуется выполнение, но - начиная с ситуации, когда ваша программа не запускалась достаточно недавно, чтобы находиться в кеше - с общими библиотеками это возможно (иногда вероятно или уверен), что ОС, драйвер или другая работающая программа уже загрузили ту же общую библиотеку, которую хочет использовать ваше приложение, и в этом случае она может находиться в кеше, и ваша программа запускается и работает быстрее.
Некоторые люди не смогли упомянуть, что со статическими библиотеками компилятор знает, какие функции нужны вашему приложению, и затем может оптимизировать его, включив только эти функции. Это может значительно сократить размер библиотеки, особенно если вы используете только очень маленькое подмножество действительно большой библиотеки!
Этот ответ может быть лучше организован. Было бы полезно составить списки для плюсов / минусов или таблицу, чтобы показать различия в каждом измерении, где есть разница.
Не могли бы вы уточнить, что «но используйте статические библиотеки, когда нужно убедиться, что двоичный файл не имеет много внешних зависимостей»? Почему в этом случае предпочтительнее статическое связывание?
Когда вы динамически компилируете, вы объявляете зависимость, которая разрешается во время выполнения. Для удовлетворения этой зависимости необходимо (а) иметь при себе копию библиотеки с программой или (б) убедиться, что библиотека установлена в целевой системе перед запуском. Это означает, что развертывание программы становится более сложным. Статическое связывание помещает все эти зависимости в программу во время компиляции, таким образом, обычно сводя развертывание к одному файлу.
«Это также позволяет вам заменить общий объект тем, который [лучше]» или - как отмечали счастливые подвески в комментариях к моему ответу на аналогичный вопрос ) - тем, что хуже. Т.е. установка обновленной версии библиотеки, которая содержит новую ошибку, означает, что ваша программа получает ошибку точно так же, как установка исправленной версии библиотеки устраняет эту ошибку для вас. Выиграй немного, проиграй немного. Вероятно, больше выиграет, чем проиграет с хорошо поддерживаемыми библиотеками.