Линкер (компьютерная программа)
Линкер или связующее вещество (также: «связывание загрузчика») представляет собой компьютерную программу , которая компилирует (соединения) отдельные программные модули , чтобы сформировать исполняемую программу. На IBM - мэйнфреймов , линкер редактор связей называется ( на английском языке).
Большинство программ содержат части или модули, которые можно использовать в других программах. Несколько скомпилированных модулей с функциями (так называемые объектные файлы ) можно объединить в библиотеки функций ( библиотеки программ ) . Код добавляется компоновщиком в основную программу, если требуется соответствующая функция.
Чтобы иметь возможность использовать программный модуль в другой программе, символьные адреса функций и переменных модуля должны быть преобразованы в адреса памяти. Компоновщик берет на себя эту задачу. Процесс компоновки происходит после компиляции и обычно является последним шагом в создании программы. Различают статическое и динамическое связывание.
Статический слева
Это статическое связывание - это процесс, который обычно происходит в конце разрабатываемой программы. В результате получилась полностью собранная программа. В случае полностью статически связанных программ, он состоит из одного файла . При статическом связывании разрешение программного модуля приложения выполняется один раз во время разработки, в отличие от динамического связывания , при котором это происходит каждый раз во время выполнения. Преимуществом статической привязки является повышенная переносимость приложения, поскольку она не зависит от предоставления таких программных модулей. B. получает инструкции от операционной системы, поскольку приложение выполняет это само. Поэтому установка программы не требуется. Недостатками являются потенциально более высокие требования к памяти, поскольку программные модули не могут использоваться другими программами, а также необходимость перекомпилировать и связывать все приложение, если улучшенная версия была опубликована для подмодуля.
Из-за этих недостатков некоторые библиотеки C в Unix-подобных операционных системах часто больше не поддерживают статическое связывание полностью. Например, glibc обеспечивает динамическое связывание модулей, влияющих на аутентификацию пользователей . Программы, использующие эти модули, всегда зависят от наличия подходящей «исполняемой версии» glibc.
Динамическое связывание
Также можно отложить разрешение имен функций и переменных до фактического выполнения программы. В этом случае мы говорим о динамическом связывании. В зависимости от операционной системы это выполняется путем загрузки полных динамических библиотек (также известных как динамически подключаемая библиотека (DLL) или разделяемая библиотека ) или путем специальной загрузки подпрограммы из библиотеки программ. Это имеет то преимущество, что впоследствии библиотеки или программы могут быть легко заменены, вызывающие программы становятся меньше, а память требуется только один раз, если несколько программ используют одни и те же компоненты. Недостатком является то, что необходимо убедиться, что правильная библиотека установлена в правильной версии (см., Например, конфликт DLL ). Перезагруженные библиотеки часто называют плагинами .
Смешанные формы статических и динамических типов ссылок являются нормой. Некоторые подпрограммы статически связаны с вызывающей программой, другие динамически перезагружаются.
Варианты, зависящие от языка при загрузке
Перегружен
« Перегрузка » означает многократное определение подпрограммы с одним и тем же идентификатором в зависимости от выбора параметра, реализуемое путем внутреннего переименования (изменение имени ). Следующие ниже примеры возможны только в C ++ или Java, но не в чистом C, где не предусмотрена перегрузка функций и попытка запроса одного из них может вызвать ошибку перевода.
Функция void function(int x);полностью отличается от void function(float x);. Обе функции имеют разные реализации, разные имена в объектном файле и не имеют ничего общего друг с другом, кроме того, что у них одно и то же имя. Так что перегружается только имя функции.
Следующие типы звонков проблемны для понимания и переводчика:
short y;
function(y);
Здесь транслятор должен решить, выполнять ли преобразование типа ( приведение ) после intили после, floatи вызвать соответствующий вариант функции. Первый случай очевиден, но многое зависит от используемого переводчика; программист не знает, что происходит в подполье машинного кода. В таких случаях некоторые переводчики выбирают то, что предположительно является правильным (что может быть неправильным в конкретном случае), в то время как другие переводчики, такие как GNU, обычно выдают ошибку, чтобы потребовать от пользователя принятия решения. Затем он должен function((float)(y));указать выбор с помощью обозначения, как при преобразовании типа.
В общем, лучше не использовать опцию перегрузки слишком свободно, а только для явных различий, таких как варианты подпрограмм с разным количеством параметров. Но и здесь комбинация параметров с аргументами по умолчанию вызывает раздражения. Вызов функции, чувствительной к параметрам, с указателями разных типов, которые не могут быть получены через базовые классы ( наследование ), можно охарактеризовать как безопасный . В любом случае переводчик проверяет правильность типа указателя и либо сообщает об ошибке, либо использует именно ту подпрограмму:
class ClassA;
class ClassB;
function(class A*); // Ist deutlich unterschieden von
function(class B*);
если ClassA и ClassB никоим образом не наследуются (наследуются) друг от друга.
Перезаписать
« Перезапись », которую следует отличать от «перегрузки», представляет собой динамическую ссылку, которая соответствующим образом реагирует в потоке программы, если метод (т.е. подпрограмма) базового класса покрывается методом с тем же именем и параметризуется в производный класс в исходном коде. Метод, соответствующий экземпляру данных, вызывается во время выполнения. Это стало возможным благодаря таблице виртуальных методов , основной концепции реализации объектно-ориентированного программирования .
Конфликты имен
В процессе связывания создается единое большое неиерархическое общее пространство имен . Это часто приводит к конфликтам имен в больших или очень сложных проектах. Для этих случаев распространены слабые ссылки , в которых последовательность ссылок определяет, какой модуль и где используется. Языки программирования, такие как B. C ++ решает проблему, обращаясь к содержимому модуля с использованием иерархически структурированных имен. Однако проблема наличия библиотеки в разных версиях остается нерешенной; Во время связывания проблема может быть решена только путем предоставления компоновщику различных путей поиска в зависимости от требуемой библиотеки - каждая из рассматриваемых библиотек отличается своим именем, но неразличима с точки зрения контента для компоновщика, поскольку то же самое в нем символы присутствуют. Однако после первой статической ссылки проблема не возникает, поскольку используемая библиотека может быть вызвана с этого момента на основе ее имени.
литература
- Леон Прессер, Джон Р. Уайт: линкеры и загрузчики . В: ACM Computing Surveys . Лента 4 , 3 (сентябрь), 1972, ISSN 0360-0300 , стр. 149–167 ( berkeley.edu [PDF; 1,3 МБ ]).
- Джон Р. Левин: Линкеры и загрузчики . Морган-Кауфман, Сан-Франциско 1999, ISBN 1-55860-496-0 .
- Стэнли Б. Липпман: Учебники по C ++ . Аддисон-Уэсли Лонгман, Амстердам 2005, ISBN 0-201-72148-1 .
- Рэндал Э. Брайант, Дэвид Р. О'Халларон: Компьютерные системы: взгляд программиста (3-е издание, особенно глава 7) . Пирсон, Бостон, 2016 г., ISBN 978-0-13-409266-9 .
веб ссылки
Индивидуальные доказательства
- ^ IBM Corporation (ed.): Операционная система 360, Редактор связей, Руководство по логике программы . Нью-Йорк 1967.
- ↑ Глава, посвященная оперативной памяти, слайд 6 (PDF) informatik.uni-ulm.de Операционные системы - Лекция по основному курсу
- ↑ a b Ульрих Дреппер : Статическое связывание считается вредным ( английский ) redhat.com. Архивировано из оригинального 21 декабря 2004 г. Проверено 13 января 2012 года : « Есть еще слишком много людей, которые думают (или даже настаивают) , что статическое связывание имеет свои преимущества. Такого никогда не было и не будет. [...] "
