Модули C ++ TS предоставляют отличную возможность для устранения препроцессора, улучшения времени компиляции и, как правило, поддержки гораздо более надежной, модульной разработки кода на C ++, по крайней мере для не шаблонного кода.
БазовыйМеханизм обеспечивает контроль над импортом и экспортом символов в обычных программах.
Однако существует основная проблема разработки библиотек для двух видов динамической загрузки: загрузка во время запуска и загрузка во время выполнения.Эта проблема связана с экспортом символов из библиотеки, что часто обсуждается с точки зрения наглядности.
Как правило, не все внешние символы блоков перевода, используемых для создания библиотеки динамических ссылок, должны быть видимы дляпользователь.Кроме того, при загрузке во время выполнения, особенно с использованием концепции плагинов, один и тот же символ должен быть экспортирован из многих одновременно загружаемых библиотек.
В Windows использование языковых расширений
__declspec(dllexport)
__declspec(dllimport)
, прикрепленных в исходном коде в качестве атрибутов символов, а в последнее время в системах gcc и clang на платформах Unix, использование
__attribute__((visibility("default")))
__attribute__((visibility("hidden")))
предназначены для поддержки предоставления и использования символов, предназначенных для обнародования библиотекой.Их использование является сложным и запутанным: в Windows макросы должны использоваться для экспорта символов во время компиляции библиотеки, но импортировать их при ее использовании.На платформах Unix видимость должна быть установлена по умолчанию как для экспорта, так и для импорта символов, компилятор сам решает, основываясь на том, найдено определение или нет: компилятор должен вызываться с
-fvisibility=hidden
переключатель.Атрибуты экспорта / импорта не требуются для статического связывания и, вероятно, должны быть преобразованы макросом в пустую строку.Создание кода и управление системой сборки, чтобы все это работало, особенно учитывая, что во время компиляции модулей перевода библиотеки в #include должен быть установлен правильный видимость символов, очень сложно, структура файла, требуемая в репозиториях, является беспорядком, исходный код замусоренс макросами и вообще .. все это катастрофа.Почти все репозитории с открытым исходным кодом НЕ ДОЛЖНЫ правильно экспортировать символы для динамического связывания, и большинство программистов понятия не имеют, что структура кода динамической библиотеки (с использованием двухуровневых пространств имен) сильно отличается от статического связывания.
Пример того, как это сделатьэто (надеюсь, правильно) можно увидеть здесь:
https://github.com/calccrypto/uint256_t
Этот репозиторий имел 2 заголовка и 2 файла реализации, пользователь встроенной библиотеки видел 2 заголовка.Теперь есть 7 заголовков и 2 файла реализации, и пользователь встроенной библиотеки увидит 5 файлов заголовков (3 с расширением include, чтобы указать, что они не должны быть включены напрямую).
Так что после этого долгогоОбдуманное объяснение, вопрос в следующем: поможет ли окончательная спецификация модулей C ++ решить проблемы с экспортом и импортом символов для динамического связывания?Можем ли мы ожидать, что сможем разрабатывать для разделяемых библиотек, не загрязняя наш код специальными расширениями и макросами поставщика?