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

#ifndef JОНNPAUL_HPP_INCLUDED

#define JOHNPAUL_HPP_INCLUDED

#pragma comment(lib, "libjohnpaul")

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

После этого изменения компоновщики Visual С++, Intel, Metrowerks, Borland и Digital Mars при компоновке кода, включающего заголовочный файл johnpaul.hpp , будут автоматически находить библиотеку libjohnpaul.lib .

В некоторых ситуациях компоновка может оказаться более сложным этапом процесса сборки, чем компиляция. Одна из наиболее часто возникающих проблем компоновки создается тогда, когда компоновщик находит неверную версию какой-либо библиотеки. Это в основном проблема Windows, где библиотеки времени выполнения и зависящие ar них библиотеки часто имеют множество вариантов. По этой причине библиотеки для Windows часто поставляются с именами, измененными так, чтобы они отражали различные конфигурации сборки. Хотя это и помогает снизить число конфликтов версий, это также затрудняет процесс компоновки, так как теперь вы должны указывать компоновщику правильное измененное имя.

По этой причине pragma commentочень полезна. Среди прочего она позволяет указать правильное имя библиотеки в заголовочном файле и избавить пользователя от необходимости разбираться в ваших соглашениях об изменении имен файлов. Если в дополнение к этому вы разработаете процесс установки, копирующий двоичные файлы в папку, автоматически используемую компоновщиком, — такую как поддиректория lib корневых директорий Visual С++, CodeWarrior или C++Builder, — то программисты смогут использовать вашу библиотеку, просто включив ее заголовочные файлы.

До сих пор все было хорошо. Но есть одна проблема: pragma commentраспознается не всеми компиляторами. Если вы хотите писать портируемый код, вы должны вызывать pragma только после того, как проверите, что она поддерживается используемым инструментарием. Например, вы можете изменить johnpaul.cpp вот так.

#ifndef JOHNPAUL_HPP_INCLUDED

#define JOHNPAUL_HPP_INCLUDED

#if defined(_MSC_VER) || \

defined(__ICL) || \

defined(__MWERKS__) && defined(_WIN32) || \

defined(__BORLANDC__) \

defined(__DMC__) \

/**/

#pragma comment (lib, "libjohnpaul")

#endif

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

Этот пример уже стал достаточно сложным, и, к сожалению, он все еще не полностью корректен: некоторые компиляторы, не поддерживающие pragma comment, для совместимости в Visual C++ определяют макрос _MSC_VER. К счастью, Boost предоставляет простое решение.

#ifndef johnpaul_hpp_included

#define JOHNPAUL_HPP_INCLUDED

#define BOOST_LIB_NAME libjohnpaul

#define BOOSTAUTO_LINK_NOMANGLE

#include

void johnpaul();

#endif // JOHNPAUL_HPP_INCLUDED

Здесь строка

#define BOOST_LIB_NAME libjohnpaul

определяет имя библиотеки, строка

#define BOOST_AUTO_LINK_NOMANGLE

указывает, что вы не хотите использовать соглашение об именах Boost, а строка

#include

вызывает pragma commentдля поддерживающих ее компиляторов.

Рецепт 1.23.

Вы хотите собрать программу, использующую экспортируемые шаблоны, что означает, что она объявляет шаблоны в заголовочных файлах с использованием ключевого слова export, а реализация шаблонов находится в файлах .cpp .

Во-первых, скомпилируйте в объектные файлы файлы .cpp , содержащие реализации шаблонов, передав компилятору опцию командной строки, необходимую для включения экспортируемых шаблонов. Затем скомпилируйте и скомпонуйте файлы .cpp , использующие экспортируемые шаблоны, передав компилятору и компоновщику опции командной строки, необходимые для включения экспортируемых шаблонов, а также опции, указывающие директории, содержащие реализации шаблонов.

Опции для включения экспортируемых шаблонов приведены в табл 1.39. Опции для указания расположения реализаций шаблонов приведены в табл. 1.40. Если ваш инструментарий в этой таблице не указан, то он, скорее всего, не поддерживает экспортируемых шаблонов.

Табл. 1.39. Опции для включения экспортируемых шаблонов

¹ Версии компилятора Intel для Linux до 9.0 использовали опцию -strict_ansi

Табл. 1.40. Опции, указывающие расположение реализаций шаблонов

Например, предположим, что вы хотите скомпилировать программу, показанную в примере 1.27. Она содержит три файла.

• Файл plus.hpp содержит объявление экспортируемого шаблона функции plus().

• Файл plus.cpp содержит определение plus().

• Файл test.cpp включает объявление — но не определение — plus()и определяет функцию main(), использующую plus().

Пример 1.27. Простая программа, использующая экспортируемые шаблоны

plus.hpp:

#ifndef PLUS_HPP_INCLUDED

#define PLUS_HPP_INCLUDED

export template

T plus(const T& lhs, const T& rhs);

#endif // #ifndef PLUS_HPP_INCLUDED

plus.cpp:

#include "plus.hpp"

template

T plus(const T& lhs, const T& rhs) {

return rhs + lhs;

}

test.cpp:

#include

#include "plus.hpp"

int main() {

std::cout << "2 + 2 = " << plus(2, 2) << "\n";

}

Чтобы скомпилировать plus.cpp в объектный файл plus.obj с помощью Comeau в Unix, перейдите в директорию, содержащую plus.cpp , plus.hpp и test.cpp , и введите следующую команду.

$ como -c --export plus.cpp

Эта команда также генерирует файл plus.et , описывающий реализацию шаблона, содержащегося в plus.cpp.

Для развлечения откройте plus.et в текстовом редакторе.

Затем скомпилируйте test.cpp в объектный файл test.obj с помощью команды:

$ como -c --export test.cpp

Наконец, скомпонуйте исполняемый файл test.exe .

$ como --export -о test test.obj

Две последние команды также можно объединить в одну.

$ como --export -o test test.cpp

Теперь можно запустить test.exe .

$ ./test

2 + 2 = 4

Теперь предположите, что файлы plus.hpp и plus.cpp находятся в директории с именем plus , a test.cpp находится в дочерней директории test . Чтобы скомпилировать и скомпоновать test.cpp , перейдите в директорию test и введите:

$ como --export --template_directory=../plus -I../plus -o test

test.cpp

C++ поддерживает две модели обеспечения определений шаблонов функций и статических данных-членов шаблонов классов: включающую (inclusion model) и раздельную (separation model) модели. Включающая модель знакома всем программистам, регулярно использующим шаблоны С++, но часто оказывается непонятной программистам, привыкшим писать код без шаблонов. Во включающей модели определение шаблона функции — или статических данных-членов шаблона класса — должно включаться в каждый исходный файл, ее использующий. В противоположность этому при использовании нешаблонных функций и данных достаточно включить в исходный файл только объявление ; определение может быть помещено в отдельный файл .cpp .