Boost.Config . Boost , Boost.Config ,

Boost.Config

Vesa Karvonen, John Maddock Beman Dawes

Распространяется под лицензией Boost Software License, версия 1.0. (См. сопроводительный файл LICENSE_1_0.txt или копию по адресуhttp://www.boost.org/LICENSE_1_0.txt)

Таблица содержания

Configuring Boost for Your Platform

Using the default boost configuration
The <boost/config.hpp> header
Using the configure script
User settable options
Advanced configuration usage
Testing the boost configuration

Boost Macro Reference

Macros that describe C++03 defects
Macros that describe optional features
Macros that describe possible C++ future features
Macros that describe C++11 features not supported
Macros that allow use of C++11 features with C++03 compilers
Macros that describe C++14 features not supported
Macros that allow use of C++14 features with C++11 or earlier compilers
Boost Helper Macros
Boost Informational Macros
Boost Deprecated Macros
Macros for libraries with separate source code

Build Time Configuration

Standard Integer Types

Overview
Rationale
Caveat emptor
Exact-width integer types
Minimum-width integer types
Fastest minimum-width integer types
Greatest-width integer types
Integer Constant Macros

Guidelines for Boost Authors

Disabling Compiler Warnings
Adding New Defect Macros
Adding New Feature Test Macros
Modifying the Boost Configuration Headers

Rationale

The problem
The solution

Acknowledgements

Configuring Boost for Your Platform

Using the default boost configuration
The <boost/config.hpp> header
Using the configure script
User settable options
Advanced configuration usage
Testing the boost configuration

Using the default boost configuration

Boost уже настроен для большинства распространенных компиляторов и платформ; вы должны иметь возможность использовать бустер «как есть». Поскольку компилятор настроен отдельно от стандартной библиотеки, конфигурация по умолчанию должна работать, даже если вы заменяете стандартную библиотеку компилятора сторонней стандартной библиотекой (например,STLport).

Использование импульса «как есть», не пытаясь перенастроить, является рекомендуемым методом использования импульса. Однако вы можете запустить скрипт конфигурации, если хотите, и есть регрессионные тесты, которые позволяют вам протестировать текущую конфигурацию усиления с помощью конкретной настройки компилятора.

Пользователи библиотеки Boost могут запросить поддержку дополнительных компиляторов или платформ, посетив нашTracи отправив запрос на поддержку.

The <boost/config.hpp> header

Повысить реализацию библиотеки через макросы конфигурации доступа

#include <boost/config.hpp>

Хотя пользователям библиотеки Boost не требуется включать этот файл напрямую или использовать эти макросы конфигурации, такое использование приемлемо. Макросы конфигурации документированы относительно их назначения, использования и ограничений, что делает их пригодными для использования как библиотекой Boost, так и пользовательским кодом.

Усилениеинформационныхиливспомогательныхмакросов предназначено для использования пользователями Boost, а также для нашего собственного внутреннего использования. Обратите внимание, однако, что макросы,ибыли разработаны для внутреннего использования библиотеками Boost, а не пользовательским кодом, поэтому они могут изменяться в любое время. Проблемы с библиотекой Boost, возникающие в результате изменений макросов конфигурации, улавливаются регрессионными тестами Boost, поэтому библиотеки Boost обновляются для учета этих изменений. Напротив, на пользовательский код библиотеки Boost могут негативно повлиять изменения макросов без предупреждения. Лучший способ быть в курсе изменений в макросах, используемых в пользовательском коде, — следить за обсуждениями в списке разработчиков Boost.

Using the configure script

	Important
	Этот скрипт конфигурации только настраивает заголовки Boost для использования с конкретным компилятором. Это не влияет на рост. Постройте или как строятся библиотеки.

Если вы знаете, что ускорение неправильно настроено для вашей конкретной настройки, и вы находитесь на платформе, подобной UNIX, то вы можете попытаться улучшить ситуацию, запустив скрипт настройки ускорения. Из командной строки оболочки вам нужно будет перейти в</libs/config/>и набрать:

<sh./configure>

Вы увидите список предметов, которые проверяются, когда сценарий проходит регрессионные тесты. Обратите внимание, что скрипт настройки автоматически определяет компилятор только в том случае, если он называется g++, c++ или CC. Если вы используете какой-либо другой компилятор, вам необходимо установить одну или несколько из следующих переменных среды:

переменный	Описание
CXX	Имя компилятора, например<`c++`> .
CXXFLAGS	Флаги компилятора для использования, например<`-O2`> .
ЛДФЛАГ	Флаги линкера для использования, например<`-L/mypath`> .
Либс	Любые библиотеки для подключения, например<`-lpthread`> .

Например, для запуска скрипта конфигурации с HP aCC можно использовать что-то вроде:

export CXX="aCC"
export CXXFLAGS="-Aa -DAportable -D__HPACC_THREAD_SAFE_RB_TREE \
   -DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE"
export LDFLAGS="-DAportable"
export LIBS="-lpthread"
sh ./configure

Как бы вы ни запускали скрипт настройки, когда он закончит, вы найдете новый заголовок -<user.hpp>- расположенный в каталоге</libs/config/>.Обратите внимание, что конфигурация не устанавливает этот заголовок в ваш усилитель, включая путь по умолчанию. Этот заголовок содержит все опции, генерируемые скриптом конфигурации, а также секцию заголовка, которая содержит параметры настройки пользователя из версии по умолчанию(находится под</boost/config/>). Есть два способа использовать этот заголовок:

Вариант 1:скопируйте заголовок в</boost/config/>так, чтобы он заменял по умолчанию user.hpp, предоставляемый бустером. Эта опция допускает только одну настройку, сгенерированную конфигурацией; разработчики бустеров должны избегать этой опции, так как она несет опасность случайного внесения модифицированного конфигурациейв репозиторий svn (за что вы не будете благодарны!).
Вариант 2:дать заголовку более запоминающееся имя и поместить его в удобное место; затем определить макрос<BOOST_USER_CONFIG>, чтобы указать на него. Например, создать новую подкаталог</boost/config/><user/>и скопировать заголовок там; например, как<multithread-gcc-config.hpp>. Затем при компиляции добавьте опцию командной строки:<-DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>">, и бустер будет использовать новый заголовок конфигурации. Эта опция позволяет генерировать более одного заголовка конфигурации и держать их отдельно от источника усиления, чтобы обновления источника не мешали вашей конфигурации.

User settable options

Есть несколько вариантов конфигурации, которые представляют собой выбор пользователя, а не дефекты компилятора или конкретные параметры платформы. Они указаны в<<boost/config/user.hpp>>и в начале заголовка, сгенерированного конфигурацией<user.hpp>. Вы можете определить их в командной строке или путем редактирования<<boost/config/user.hpp>>, они перечислены в следующей таблице:

Макро	Описание
<`BOOST_USER_CONFIG`>	При определении он должен указывать имя файла конфигурации пользователя для включения перед любыми файлами конфигурации усиления. Когда не определено, по умолчанию<`<boost/config/user.hpp>`> .
<`BOOST_COMPILER_CONFIG`>	При определении он должен указывать имя используемого файла конфигурации компилятора. Определение этого исключает логику выбора компилятора и устраняет зависимость от заголовка, содержащего эту логику. Например, если вы используете gcc, то вы можете определить BOOST_COMPILER_CONFIG<`<boost/config/compiler/gcc.hpp>`>.
<`BOOST_STDLIB_CONFIG`>	При определении он должен указывать имя стандартного файла конфигурации библиотеки для использования. Определение этого вырезает стандартную логику выбора библиотеки и устраняет зависимость от заголовка, содержащего эту логику. Например, если вы используете STLport, то вы можете определить<`BOOST_STDLIB_CONFIG`>до<`<boost/config/stdlib/stlport.hpp>`> .
<`BOOST_PLATFORM_CONFIG`>	При определении он должен указывать имя используемого файла конфигурации платформы. Определение этого исключает логику выбора платформы и устраняет зависимость от заголовка, содержащего эту логику. Например, если вы компилируете на Linux, то вы можете определить<`BOOST_PLATFORM_CONFIG`>до<`<boost/config/platform/linux.hpp>`> .
<`BOOST_NO_COMPILER_CONFIG`>	При определении ни один файл конфигурации компилятора не выбирается или не включается, не определяет, когда компилятор полностью соответствует стандарту или где заголовок пользователя (см.<`BOOST_USER_CONFIG`>), имел какие-либо необходимые параметры, добавленные к нему, например, сгенерированным автоконфигурационным сценарием.
<`BOOST_NO_STDLIB_CONFIG`>	При определении не выбирается или не включается стандартный файл конфигурации библиотеки, не определяется, когда стандартная библиотека полностью соответствует стандарту, или где в заголовке пользователя (см.<`BOOST_USER_CONFIG`>) были какие-либо необходимые параметры, добавленные к нему, например, сгенерированным автоконфигурационным сценарием.
<`BOOST_NO_PLATFORM_CONFIG`>	При определении не выбирается и не включается файл конфигурации платформы, определяется, когда платформа полностью соответствует стандарту (и не имеет полезных дополнительных функций), или когда в заголовке пользователя (см.<`BOOST_USER_CONFIG`>) были какие-либо необходимые параметры, добавленные к нему, например, сгенерированным автоконфигурационным сценарием.
<`BOOST_NO_CONFIG`>	Эквивалентно определению всех<`BOOST_NO_COMPILER_CONFIG`>,<`BOOST_NO_STDLIB_CONFIG`>и<`BOOST_NO_PLATFORM_CONFIG`>.
<`BOOST_STRICT_CONFIG`>	Нормальным поведением для версий компилятора, которые являются более новыми, чем последняя известная версия, является предположение, что они имеют все те же дефекты, что и последняя известная версия. Установив это определение, можно предположить, что версии компилятора, которые являются более новыми, чем последняя известная версия, полностью соответствуют стандарту. Это, вероятно, наиболее полезно для разработчиков или тестировщиков, а также для тех, кто хочет использовать бустер для тестирования версий бета-компилятора.
<`BOOST_ASSERT_CONFIG`>	Когда этот флаг установлен, если конфигурация находит что-то неизвестное, то она остановится с ошибкой, а не продолжится. Тестировщики ускоренной регрессии должны установить это определение, как и любой, кто хочет быстро проверить, поддерживается ли импульс на их платформе.
<`BOOST_DISABLE_THREADS`>	При определении отключается поддержка потоков, даже если компилятор в его текущем режиме трансляции поддерживает несколько потоков.
<`BOOST_DISABLE_WIN32`>	При определении отключается использование API-интерфейсов Win32, даже если они доступны. В этом случае<`BOOST_DISABLE_THREADS`>,<`BOOST_HAS_PTHREADS`>,<`BOOST_HAS_PTHREADS`>. Эта опция может быть установлена автоматически системой конфигурации, когда она обнаруживает, что компилятор находится в «строгом режиме».
<`BOOST_DISABLE_ABI_HEADERS`>	Препятствует включению любых префиксов/суффиксов, которые обычно управляют такими вещами, как упаковка структуры и выравнивание.
<`BOOST_ABI_PREFIX`>	Заголовок префикса для включения вместо любого усиления. Конфигурация обычно выбирает, любая замена должна настраивать параметры упаковки структуры и выравнивания по мере необходимости.
<`BOOST_ABI_SUFFIX`>	Заголовок суффикса для включения вместо любого усилителя. Конфигурация обычно выбирает, любая замена должна отменить эффекты заголовка префикса.
<`BOOST_ALL_DYN_LINK`>	Вынуждает все библиотеки, имеющие отдельный источник, быть связанными как библиотеки dll, а не статические библиотеки в Microsoft Windows (этот макрос используется для включения модификаторов<`__declspec(dllimport)`>, так что компилятор знает, какие символы искать в dll, а не в статической библиотеке). Обратите внимание, что могут быть некоторые библиотеки, которые могут быть только статически связаны (например, Boost.Test) и другие, которые могут быть только динамически связаны (например, Boost.Thread), в этих случаях этот макрос не имеет эффекта.
<`BOOST_`>Что есть<`_DYN_LINK`>	Вынуждает библиотеку «что угодно» быть связанной как dll, а не статическая библиотека в Microsoft Windows: заменить частьWHATEVERна имя библиотеки, на которую вы хотите динамически ссылаться, например, использовать<`BOOST_DATE_TIME_DYN_LINK`>или<`BOOST_REGEX_DYN_LINK`>и т. Д. (это макрос используется для включения модификаторов<`__declspec(dllimport)`>, так что компилятор знает, какие символы искать в dll, а не в статической библиотеке). Обратите внимание, что могут быть некоторые библиотеки, которые могут быть только статически связаны (например, Boost.Test) и другие, которые могут быть только динамически связаны (например, Boost.Thread), в этих случаях этот макрос не поддерживается.
<`BOOST_ALL_NO_LIB`>	Сообщает системе конфигураций не автоматически выбирать, против каких библиотек ссылаться. Обычно, если компилятор поддерживает #pragma lib, то правильный вариант сборки библиотеки будет автоматически выбран и связан с ним, просто включив один из заголовков этой библиотеки. Этот макрос отключает эту функцию.
<`BOOST_`>Что бы ни случилось<`_NO_LIB`>	Сообщает системе конфигураций не автоматически выбирать, какую библиотеку связать с библиотекой «что угодно», заменитьWHATEVERв макро-имени на имя библиотеки; например<`BOOST_DATE_TIME_NO_LIB`>или<`BOOST_REGEX_NO_LIB`>. Обычно, если компилятор поддерживает<`#pragma lib`>, то правильный вариант сборки библиотеки будет автоматически выбран и связан с ним, просто путем включения одного из заголовков этой библиотеки. Этот макрос отключает эту функцию.
<`BOOST_LIB_DIAGNOSTIC`>	Вызывает автоматическое связывание кода с выводом диагностических сообщений, указывающих название библиотеки, выбранной для связывания.
<`BOOST_LIB_BUILDID`>	Если вы построили Boost с помощью опции<`--buildid`>, то установите этот макрос на то же значение, что и перешли на bjam. Например, если вы построили с помощью<`bjamaddress-model=64--buildid=amd64`>, то компилируйте свой код с<`-DBOOST_LIB_BUILDID=amd64`>, чтобы убедиться, что правильные библиотеки выбраны во время ссылки.
<`BOOST_LIB_TOOLSET`>	Переопределяет название набора инструментов части названия библиотеки, связанного с; примечание, если определено, это должно быть определено к цитируемой строке буквально, например «abc».

Advanced configuration usage

Example 1: creating our own frozen configuration
Example 2: skipping files that you don't need
Example 3: using configure script to freeze the boost configuration

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

Конфигурация Boost структурирована таким образом, что сначала включается конфигурация пользователя (по умолчанию, если<BOOST_USER_CONFIG>не определено). Это настраивает любые пользовательские политики и дает возможность пользовательской конфигурации влиять на то, что произойдет дальше.

Далее включены компилятор, стандартная библиотека и файлы конфигурации платформы. Они включаются через макросы (<BOOST_COMPILER_CONFIG>и т.д.,см. макросы, устанавливаемые пользователем), и если соответствующий макрос не определен, то для их установки включается отдельный заголовок, который определяет, какой компилятор/стандартная библиотека/платформа используется. Конфигурацию можно заставить полностью игнорировать эти заголовки, если установлен соответствующий макрос<BOOST_NO_XXX>(например,<BOOST_NO_COMPILER_CONFIG>для отключения включения любого файла конфигурации компилятора -см. макросы, устанавливаемые пользователем).

Наконец, заголовок конфигурации бустера включает в себя; этот заголовок содержит любой код конфигурации пластины котла - например, когда один макрос бустера устанавливается, подразумевается, что также должен быть установлен другой.

Следующие примеры использования представляют лишь некоторые из возможностей:

Example 1: creating our own frozen configuration

Давайте предположим, что мы развиваем Visual C++ 6 и STLport 4.0. Предположим также, что в ближайшее время мы не намерены обновлять наш компилятор или стандартную библиотеку. Чтобы избежать разрыва зависимостей при обновлении, мы, возможно, захотим «заморозить» наши заголовки конфигурации, так что нам придется перестраивать наш проект только в том случае, если сам код повышения изменился, а не потому, что конфигурация повышения была обновлена для более поздних версий Visual C++ или STLport. Начнем с понимания того, что используемые файлы конфигурации:<<boost/config/compiler/visualc.hpp>>для компилятора,<<boost/config/stdlib/stlport.hpp>>для стандартной библиотеки и<<boost/config/platform/win32.hpp>>для платформы. Далее мы создадим собственный каталог конфигурации<boost/config/mysetup/>и скопируем туда файлы конфигурации. Наконец, откройтеи отредактируйте следующее:

#define BOOST_COMPILER_CONFIG "boost/config/mysetup/visualc.hpp"
#define BOOST_STDLIB_CONFIG "boost/config/mysetup/stlport.hpp"
#define BOOST_USER_CONFIG "boost/config/mysetup/win32.hpp"

Теперь, когда вы используете усилитель, его заголовок конфигурации перейдет прямо к нашим «замороженным» версиям и проигнорирует версии по умолчанию, вы теперь будете изолированы от любых изменений конфигурации при увеличении обновления. Этот метод также полезен, если вы хотите модифицировать некоторые файлы конфигурации усиления; например, если вы работаете с выпуском бета-компилятора, который еще не поддерживается усилением.

Example 2: skipping files that you don't need

Предположим, что вы используете усилитель с компилятором, который полностью соответствует стандарту; вас не интересует тот факт, что в старых версиях вашего компилятора могут быть ошибки, потому что вы знаете, что ваша текущая версия не нуждается в настройках макросов конфигурации. В таком случае вы можете определить<BOOST_NO_COMPILER_CONFIG>либо в командной строке, либо ви вообще пропустить заголовок конфигурации компилятора (на самом деле вы пропустите два заголовка, один из которых определяет, что такое компилятор, и один, который настраивает усилитель для него). Это имеет два последствия: первый заключается в том, что нужно компилировать меньше кода, а второй — в том, что вы удалили зависимость от двух заголовков.

Example 3: using configure script to freeze the boost configuration

Если вы работаете на Unix-подобной платформе, то вы можете использовать скрипт конфигурации для создания «замороженной» конфигурации на основе вашей текущей настройки компилятора -см.

Testing the boost configuration

Библиотека конфигураций бустера предоставляет полный набор программ регрессионного тестирования в подкаталоге</boost/config/><test/>:

Файл	Описание
<`config_info.cpp`>	Распечатывает подробное описание настройки компилятора/стандартной библиотеки/платформы, а также текущую конфигурацию усиления. Информация, предоставленная этой программой, полезна при настройке файлов конфигурации усиления. Если вы сообщаете, что импульс неправильно настроен для вашего компилятора/библиотеки/платформы, пожалуйста, включите вывод из этой программы, сообщая о необходимых изменениях.
<`config_test.cpp`>	Монолитическая программа испытаний, которая включает в себя большинство отдельных тестовых случаев. Это обеспечивает быструю проверку, чтобы увидеть, правильно ли настроен импульс для компилятора / библиотеки / платформы.
<`limits_test.cpp`>	Проверяет реализацию стандартной библиотеки<`std::numeric_limits`>(или ее замену, если<`BOOST_NO_LIMITS`>определено). Этот тестовый файл не работает с большинством версий numeric_limits, в основном из-за того, что некоторые компиляторы обрабатывают NAN и бесконечность.
<`no_*pass.cpp`>	Отдельные файлы проверки дефектов компилятора. Каждый из них должен компилироваться, если нет, то необходимо определить соответствующий макрос<`BOOST_NO_XXX`>- см. каждый тестовый файл для конкретных деталей.
<`no_*fail.cpp`>	Отдельные файлы проверки дефектов компилятора. Каждый из них не должен компилироваться, если он это делает, то соответствующий<`BOOST_NO_XXX`>макрос определяется, когда он не должен быть - см. каждый тестовый файл для конкретных деталей.
<`has_*pass.cpp`>	Отдельные тестовые файлы. Если один из них не компилирует, то соответствующий<`BOOST_HAS_XXX`>макрос определяется, когда его не должно быть - см. каждый тестовый файл для конкретных деталей.
<`has_*fail.cpp`>	Отдельные тестовые файлы. Если один из них действительно компилирует, то можно безопасно определить соответствующий<`BOOST_HAS_XXX`>макрос - см. каждый тестовый файл для конкретных деталей.

Хотя вы можете запускать тесты регрессии конфигурации в качестве отдельных тестовых файлов, их довольно много, поэтому есть несколько ярлыков, которые помогут вам:

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

В качестве альтернативы вы можете запустить скрипт конфигурации, как это:

<./configure --enable-test>

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

Если вы сообщаете о результатах этих тестов для новой платформы/библиотеки/компилятора, то, пожалуйста, включите журнал полного вывода компилятора, выход из<config_info.cpp>и результаты теста на пропуск/отказ.

Статья Boost.Config раздела Boost.Config может быть полезна для разработчиков на c++ и boost.