Преимущества динамического связывания с любой утилитой ld по сравнению с dlfcn API?

Question

Я изучаю независимый от платформы код и нашел упоминание об API dlfcn.Впервые я упомянул об этом и провел дальнейшие исследования.Теперь, надеюсь, мое отсутствие опыта / понимания кода, независимого от платформы, а также компиляции / компоновки не будет показано в этом посте, но для меня API dlfcn просто позволяет нам делать то же динамическое связывание программно, что и утилита ld.Если у меня есть неправильные представления, поправьте меня, как я хотел бы знать.Что касается того, что я знаю об утилите ld и API dlfcn, у меня есть несколько вопросов.

Каковы преимущества использования утилиты ld по сравнению с API dlfcn для динамического связывания?

Моей первой мыслью было, что API dlfcn кажется пустой тратой моего времени, поскольку мне нужно запрашивать указатели на функции вместо того, чтобы ld проверял таблицу символов на наличие неопределенных символов и затем связывал их.Точно так же ld делает все для меня, в то время как я должен делать все вручную с помощью API dlfcn (т.е. открыть / загрузить библиотеку, получить указатель на функцию, закрыть библиотеку и т. Д.).Но на второй взгляд я подумал, что здесь могут быть некоторые преимущества.Одним из них является то, что мы можем загрузить библиотеку из памяти после того, как мы покончим с этим.

Таким образом, память может быть сохранена, если мы знали, что нам не нужно использовать библиотеку все время.Я не уверен, есть ли какое-либо управление "память / библиотека" для библиотек, динамически связанных с ld?Точно так же я не уверен в том, какие сценарии / среды нам было бы интересно использовать API dlfcn для сохранения упомянутой памяти, так как кажется, что это не будет проблемой в современных системах.Полагаю, можно использовать библиотеку в системе с очень очень очень ограниченными ресурсами (может быть, со встроенной системой?).

Какие еще могут быть преимущества или недостатки?

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

Если бы я делал код, независимый от платформы, который зависел от системных вызовов, я мог бы видеть, как я добивался кода, независимого от платформы, кодируя водин из трех стилей:

1. Логическое ветвление непосредственно в коде моей библиотеки через макросы.Примерно так:
2. Создание общих функций системного вызова и использование их в коде моей библиотеки.Примерно так:
3. Аналогично одному, но добавить слой абстракции с помощью API dlfcn

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

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

Answer 1

dlfcn и ld не решают одну и ту же проблему: на самом деле вы можете использовать обоих в своем проекте.

API dlfcn предназначен для поддержки подключаемых архитектур, в которых вы определяетеинтерфейс, который модули должны реализовать.Затем приложение может загружать различные реализации этого интерфейса по разным причинам (расширяемость, настройка и т. Д.).

ld, ну, связывает библиотеки вашего запроса приложения, но делает это при compile время, а не во время выполнения.Он никоим образом не поддерживает архитектуры плагинов, поскольку ld связывает объекты, указанные в командной строке.

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

Что касается вашего второго вопроса, я думаю, что лучший образец - второй.Ветвление «непосредственно в коде» может сбивать с толку, потому что не сразу очевидно, что выполняют две ветви, что хорошо определено, если вы определите правильную абстракцию и реализуете ее с использованием нескольких ветвей для каждой поддерживаемой архитектуры.Использование API dlfcn довольно бессмысленно, потому что у вас нет универсального интерфейса для вызова (это именно тот аргумент, который поддерживает второй шаблон), поэтому он просто добавляет раздувание в ваш код.

HTH

Answer 2

Я не думаю, что динамическое связывание сильно поможет вам с независимостью от платформы.
Ваш второй вариант кажется разумным способом достижения независимости от платформы.Большая часть кода просто вызывает независимую от вашей платформы обертку, в то время как небольшая ее часть «грязная» с ifdefs.
Я не понимаю, как здесь помогает динамическая загрузка.минусы для динамической загрузки:
1. Минусы:
a.Не "прямой" способ, требует больше работы.
б.Запрещает стандартным инструментам (например, ldd) анализировать зависимости (что помогает вам недопонимать то, что вам нужно для успешного запуска).
2. Плюсы:
a.Позволяет загружать только то, что вам нужно (например, в зависимости от аргументов командной строки), или выгружать то, что вам не нужно.Это может сэкономить память.
b.Позволяет генерировать имена библиотек более сложными способами (например, читать список плагинов из файла конфигурации).