Преимущества статического связывания

Question

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

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

Спасибо за любое просвещение!

Answer 1

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

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

Answer 2

Статически исполняемый файл содержит все необходимые ему объекты, поэтому при выполнении не будет вызываться внешняя DLL. Преимущество заключается в том, что он переносим на многие платформы независимо от того, какая версия DLL установлена ​​в этой системе. БОЛЬШОЙ недостаток заключается в том, что вы, вероятно, тратите место на диске, так как включаете в свой исполняемый код, который уже присутствует в системных / внешних DLL. Более того, я думаю, но я не очень уверен, что библиотеки DLL загружаются в основную память только один раз, независимо от того, сколько исполняемых файлов используют их, но если вы статически связываете объекты библиотеки внутри вашего исполняемого файла, вы загружаете один и тот же код дважды (один для DLL, используемой остальными программами, и одну для вашего исполняемого файла). С другой стороны, это может быть преимуществом, а не недостатком, поскольку исполняемый файл содержит только те объекты необходимых ему внешних библиотек, а не всю библиотеку. DLL загружается в память в целом, когда это требуется приложению.

Статическое связывание идеально подходит для компиляции небольших приложений, которые вы хотите перенести из одной системы в другую в качестве небольшого инструмента. То есть для меня было действительно полезно иметь статически скомпилированную версию tcpdump, когда она не была включена в каждый дистрибутив Linux. Он должен был работать на каждом Linux, независимо от того, какая версия ядра, glibc или других системных библиотек. Возможно, это не имеет особого смысла в мире Windows, поскольку платформы гораздо более однородны. Если вы компилируете для Windows XP / NET vX.X, он будет работать на многих компьютерах. Если вы скомпилируете что-то для Debian X.X, это, безусловно, не будет работать на старых / новых Debian или других дистрибутивах, таких как Redhat.

Эта тема также может решить ваши вопросы.

Answer 3

Я не уверен, что статическая линковка действительно хорошая идея в C #, если честно, по миллиону причин. Одна из причин заключается в том, что в отличие от языков, таких как C или C ++, в C # есть концепция сборок, которые в основном являются исполняемыми файлами или DLL.

Теперь, если вы хотите статически связать вещи в .NET, вы либо

• Объединение классов из нескольких сборок в одну сборку. Это сломало бы многое, например, модификатор доступа " internal ".
• иметь более одной сборки в одном исполняемом файле. Это сделало бы всю концепцию сборок бесполезной, однако, и потребовало бы изменить подход к отражению в .NET Framework.

Я уверен, что есть хитрый способ избежать этих проблем, но я не совсем вижу смысла в статическом связывании в управляемой среде, такой как .NET или Java. Я имею в виду, что статическое связывание действительно улучшает производительность, но не слишком. И мы все равно не используем управляемые языки для их скорости выполнения.

Еще одна проблема - это DLL-ад, но в .NET это в любом случае решаемая проблема.

Answer 4

Все необходимые материалы упакованы в исполняемый файл. Таким образом,

• Вам не нужно устанавливать какие-либо другие материалы. Просто скопируйте и запустите. Или беги, где это. Нет установщика, никаких предостережений, никаких странных ошибок из-за неправильной версии DLL. Вот и все.
• Также ваши пользователи могут наслаждаться этой простотой. Это обычно намного важнее. Никто не приветствует установку зависимостей. Особенно, если он такой огромный, как .NET Framework.

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

Answer 5

Есть хороший пример различия между статическим и динамическим связыванием. Если вы посмотрите на проект InkScape, вы найдете InkscapePortable и InkScape. InkscapePortable будет работать с флешки. InkScape не будет.