C++. Сборник рецептов

Если вам требуется скомпилировать код, не соответствующий стандарту, вначале проверьте, будет ли он компилироваться при использовании опций, приведенных в табл. 1.37 и 138. Если нет, то некоторые компиляторы предлагают набор «дробных» опций совместимости, позволяющих использовать некоторые несовместимые конструкции, но запрещающих другие. Например, Comeau предоставляет опцию – -long_long, указывающую на необходимость распознавания типа long long. Наконец, некоторые компиляторы предоставляют опции, заставляющие их сообщать о большинстве нарушений стандарта как о предупреждениях, а не ошибках. Например, GCC для этой цели предоставляет опцию – pedantic, a Comeau для Windows предоставляет опцию – -a, а для других платформ — опции – -strict_warnings или – a.

Смотри также

Рецепт 1.2.

1.25. Указание определенной библиотеки для автоматической компоновки с исходным файлом

Проблема

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

Решение

При программировании для Windows с использованием инструментария Visual C++, Intel, Metrowerks, Borland или Digital Mars для указания имен и (при необходимости) путей готовых библиотек, с которыми должен компоноваться код, включающий заголовочные файлы вашей библиотеки, используйте в этих заголовочных файлах pragma comment.

Например, предположим, что вы хотите распространить библиотеку из примера 1.1, состоящую из статической библиотеки libjohnpaul.lib и заголовочного файла johnpaul.hpp. Измените этот заголовочный файл так, как показано в примере 1.26.

Пример 1.26. Использование pragma comment

#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 <boost/config/auto_link.hpp>

void johnpaul;

#endif // JOHNPAUL_HPP_INCLUDED

Здесь строка

#define BOOST_LIB_NAME libjohnpaul

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

#define BOOST_AUTO_LINK_NOMANGLE

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

#include <boost/config/auto_link.hpp>

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

Смотри также

Рецепт 1.23.

1.26. Использование экспортируемых шаблонов

Проблема

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

Решение

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