Д. Стефенс - C++. Сборник рецептов
- Название:C++. Сборник рецептов
- Автор:
- Жанр:
- Издательство:КУДИЦ-ПРЕСС
- Год:2007
- Город:Москва
- ISBN:5-91136-030-6
- Рейтинг:
- Избранное:Добавить в избранное
-
Отзывы:
-
Ваша оценка:
Д. Стефенс - C++. Сборник рецептов краткое содержание
Данная книга написана экспертами по C++ и содержит готовые рецепты решения каждодневных задач для программистов на С++. Один из авторов является создателем библиотеки Boost Iostreams и нескольких других библиотек C++ с открытым исходным кодом. В книге затрагивается множество тем, вот лишь некоторые из них: работа с датой и временем; потоковый ввод/вывод; обработка исключений; работа с классами и объектами; сборка приложений; синтаксический анализ XML-документов; программирование математических задач. Читатель сможет использовать готовые решения, а сэкономленное время и усилия направить на решение конкретных задач.
C++. Сборник рецептов - читать онлайн бесплатно полную версию (весь текст целиком)
Интервал:
Закладка:
Например, чтобы скомпилировать исходные файлы из примера 1.2 в объектные файлы с помощью компилятора Borland, предполагая, что директория, в которой находятся инструменты Borland, включена в переменную PATH
, перейдите в директорию georgeringo и введите следующие команды.
> bcc32 -с -a -WR -о george.obj george.cpp
george.cpp:
> bcc32 -c -q -WR -o ringo.obj ringo.cpp
ringo.cpp:
> bcc32 -c -q -WR -DGERORGERINGO_DLL -o georgeringo.obj georgeringo.cpp
georgeringo.cpp:
Здесь опция компилятора -WR используется для указания того, что применяется динамический вариант рабочей библиотеки. Эти три команды сгенерируют объектные файлы george.obj , ringo.obj и georgeringo.obj . Затем введите команду:
> bcc32 -q -WD -WR -elibgeorgeringo.dll george.obj ringo.obj georgeringo.obj
Она сгенерирует динамическую библиотеку libgeorgeringo.dll . Наконец, введите команду:
> implib -с libgeorgeringo.lib libgeorgeringo.dll
Она сгенерирует библиотеку импорта libgeorgeringo.lib .
То, как обрабатываются динамические библиотеки, в основном зависит от операционной системы и инструментария. С точки зрения программиста, два наиболее значительных отличия — это:
Динамические библиотеки могут содержать определения классов, функции и данные. На некоторых платформах все такие символы автоматически доступны для кода, использующего динамическую библиотеку, а другие системы предлагают программистам различные возможности управления доступом к этим символам. Наличие возможности определить, какие символы и в каком случае должны быть видны, очень полезно, так как дает программисту возможность более явного управления внешним интерфейсом его библиотеки и часто приводит к более высокой производительности. Однако она также делает более сложными сборку и использование динамических библиотек.
В случае с большинством инструментариев для Windows, чтобы символ, определенный в динамической библиотеке, был доступен коду, использующему эту библиотеку, он должен быть явно экспортирован при сборке динамической библиотеки и импортирован при сборке исполняемого файла или другой динамической библиотеки, использующей эту библиотеку. Некоторые инструменты для Unix также предлагают такие возможности. Это верно для последних версий GCC для некоторых платформ, для Metrowerks на Mac OS X и для Intel для Linux. Однако в некоторых случаях нет никакого выбора, кроме как сделать все символы видимыми.
В Unix динамическая библиотека может быть указана как входной файл компоновщика при компоновке кода, использующего эту динамическую библиотеку. В Windows, кроме случаев использования GCC, динамические библиотеки не указываются напрямую как вход компоновщика, а вместо этого используется библиотека импорта или файл определения модуля.
Библиотеки импорта, грубо говоря, являются статическими библиотеками, содержащими информацию, необходимую для вызова функций, содержащихся в DLL, во время исполнения. Нет необходимости знать, как они работают, надо только знать, как их создавать и использовать. Большинство компоновщиков создает библиотеки импорта автоматически при сборке DLL, но в некоторых случаях может оказаться необходимо использовать отдельный инструмент, который называется библиотекарь импорта (import librarian) . В табл. 1.11 с целью избежать запутанного синтаксиса командной строки, требуемого компоновщиком Borland ilink32.exe , я использовал библиотекарь импорта Borland implib.exe .
Файл определения модуля, или файл .def — это текстовый файл, который описывает функции и данные, экспортируемые из DLL. Файл .def может быть написан вручную или автоматически сгенерирован каким-либо инструментом. Пример файла .def для библиотеки libgeorgeringo.dll показан в примере 1.5.
Пример 1.5. Файл определения модуля для libgeorgeringo.dll
LIBRARY LIBGEORGERINGO.DLL
EXPORTS
Georgeringo @1
Имеется два стандартных метода экспорта символов из Windows DLL.
• Использование атрибута __declspec(dllexport)
в заголовочных файлах DLL и сборка библиотеки импорта, предназначенной для применения при сборке кода, использующего эту DLL.
Атрибут __dеclspec(dllexport)
должен указываться в начале объявления экспортируемой функции или данных, вслед за какими-либо спецификаторами сборки, и сразу за ним должно следовать ключевое слово class
или struct
для экспортируемого класса. Это проиллюстрировано в примере 1.6. Заметьте, что __declspec(dllexport)
не является частью языка С++; это расширение языка, реализованное для большинства компиляторов для Windows.
• Создание файла .def , описывающего функции и данные, экспортируемые из динамической библиотеки.
Пример 1.6. Использование атрибута __declspec(dllexport)
__declspec(dllexport) int m = 3; // Экспортируемое определение данных
extern __declspec(dllexport) int n; // Экспортируемое объявление данных
__declspec(dllexport) void f(); // Экспортируемое объявление функции class
__declspec(dllexport) 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.
Интервал:
Закладка: