Д. Стефенс - C++. Сборник рецептов

Использование файла .def имеет несколько преимуществ — например, он может позволить осуществлять доступ к функциям в DLL по номеру, а не по имени, что сокращает размер DLL. Он также устраняет необходимость запутанных директив препроцессора, таких как показанные в примере 1.2 в заголовочном файле georgeringo.hpp . Однако он также имеет и несколько серьезных недостатков. Например, файл .def не может использоваться для экспорта классов. Более того, можно забыть обновить свой файл .def при добавлении, удалении или изменении функций в вашей DLL. Таким образом, я рекомендую вам всегда использовать __declspec(dllexport). Чтобы изучить полный синтаксис файлов .def , а также научиться их использовать, обратитесь к документации по своему инструментарию.

Как есть два способа экспорта символов из DLL, так есть и два способа импорта символов.

• В заголовочных файлах, включенных в исходный код, использующий DLL, используйте атрибут __declspec(dllimport)и при сборке этого кода передайте библиотеку импорта компоновщику.

• При сборке кода, использующего DLL, укажите файл .def .

Как и в случае с экспортом символов, я рекомендую вместо файлов .def использовать в вашем исходном коде атрибут __declspec(dllimport). Атрибут __declspec(dllimport)используется точно так же, как и атрибут __declspec(dllexport), обсуждавшийся ранее. Аналогично __declspec(dllexport)атрибут __declspec(dllimport)не является частью языка С++, а является расширением языка, реализованным для большинства компиляторов для Windows.

Если вы выбрали использование __declspec(dllexport)и __declspec(dllimport), вы должны убедиться, что при сборке DLL использовали __declspec(dllexport), а при компиляции кода, использующего эту DLL, использовали __declspec(dllimport). Одним из подходов является использование двух наборов заголовочных файлов: одного для сборки DLL, а другого для компиляции кода, использующего эту DLL. Однако это неудобно, так как сложно одновременно сопровождать две отдельные версии одних и тех же заголовочных файлов.

Вместо этого обычно используют определение макроса, который при сборке DLL расширяется как __declspec(dllexport), а в противном случае — как __declspec(dllimport). В примере 1.2 я использовал для этой цели макроопределение GEORGERINGO_DECL. В Windows, если определен символ GEORGERINGO_SOURCE, то GEORGERINGO_DECLраскрывается как __declspec(dllexport), а в противном случае — как __declspec(dllimport). Описанный результат вы получите, определив GEORGERINGO_SOURCEпри сборке DLL libgeorgeringo.dll , но не определяя его при компиляции кода, использующего libgeorgeringo.dll .

Порты GCC Cygwin и MinGW, обсуждавшиеся в рецепте 1.1, работают с DLL по-другому, нежели остальные инструменты для Windows. При сборке DLL с помощью GCC по умолчанию экспортируются все функции, классы и данные. Это поведение можно изменить, использовав опцию компоновщика --no-export-all-symbols , применив в исходных файлах атрибут __declspec(dllexport)или используя файл .def . В каждом из этих трех случаев, если вы не используете опцию --export-all-symbols , чтобы заставить компоновщик экспортировать все символы, экспортируются только те функции, классы и данные, которые помечены атрибутом __declspec(dllexport)или указаны в файле .def .

Таким образом, инструментарий GCC можно использовать для сборки DLL двумя способами: как обычный инструментарий Windows, экспортирующий символы явно с помощью __declspec, или как инструментарий Unix, автоматически экспортирующий все символы [1] Экспорт символов с помощью __declspec(dllexport) иногда неправильно называют неявным экспортом . В примере 1.2 и табл. 1.11 я использовал последний метод. Если вы выберете этот метод, вы должны в целях предосторожности использовать опцию --export-all-symbols — на тот случай, если у вас окажутся заголовки, содержащие __declspec(dllexport).

GCC отличается от других инструментов для Windows и еще в одном: вместо того чтобы передавать компоновщику библиотеку импорта, связанную с DLL, вы можете передать саму DLL. Это обычно быстрее, чем использование библиотеки импорта. Однако это может привести к проблемам, так как в одной и той же системе может существовать несколько версий одной DLL, и вы должны быть уверены, что компоновщик выберет правильную версию. В табл. 1.11 при демонстрации того, как создавать библиотеки импорта с помощью GCC, я решил не использовать эту возможность.

В случае с Cygwin библиотека импорта для DLL xxx.dll обычно называется xxx.dll.a , в то время как в случае с MinGW она обычно называется xxx.a . Это просто вопрос соглашения.