Заголовок<<boost/config/warning_disable.hpp>>может использоваться для отключения определенных предупреждений компилятора, которые трудно или невозможно удалить иным образом.

Обратите внимание:

В настоящее время он отключает следующие предупреждения:

Когда вам нужно добавить новый макрос дефекта - либо для исправления проблемы с существующей библиотекой, либо при добавлении новой библиотеки - доведите проблему до простого тестового случая; часто в этот момент могут проявиться другие (возможно, лучшие) обходные пути. Во-вторых, всегда размещайте тестовый код в списке рассылки и приглашайте комментарии; помните, что C++ сложен и что иногда то, что может показаться дефектом, на самом деле может оказаться проблемой с пониманием авторами стандарта.

Когда вы называете макрос, следуйте<BOOST_NO_>.Кое-чтоусловное обозначение, так что очевидно, что это макроотчет о дефекте.

Наконец, добавьте программу тестирования в регрессионные тесты. Вам нужно будет поместить тест-кейс в файл<.ipp>со следующими комментариями в верхней части:

//  MACRO:         BOOST_NO_FOO
//  TITLE:         foo
//  DESCRIPTION:   If the compiler fails to support foo

Эти комментарии обрабатываются по сценарию autoconf, поэтому убедитесь, что формат соответствует заданному. Файл должен быть назван «<boost_no_foo.ipp>», где foo — описание дефекта — попробуйте сохранить имя файла под ограничением имени файла символа Mac 30. Вам также потребуется предоставить функциональный прототип «<inttest()>», который заявлен в пространстве имен с тем же названием, что и макрос, но во всех нижних случаях, и который возвращает ноль на успех:

namespace boost_no_foo {
int test()
{
    // test code goes here:
    //
    return 0;
}
}

После того, как тестовый код установлен в libs/config/test, обновление системы тестирования конфигурации происходит следующим образом:

Тогда вы должны:

Когда вам нужно добавить макрос, который описывает функцию, которая не требуется стандартом, следуйте соглашению для добавления нового макроса дефекта (выше), но вызовите макрос<BOOST_HAS_FOO>и назовите тестовый файл<boost_has_foo.ipp>. Не добавляйте макросы для тестирования функций без необходимости, если есть конкретный макрос платформы, который уже можно использовать (например,<_WIN32>,<__BEOS__>или<__linux>), чтобы идентифицировать функцию, а затем используйте эту функцию. Постарайтесь сохранить макрос в группе функций или имени заголовка, а не в одном конкретном API (например,<BOOST_HAS_NL_TYPES_H>, а не<BOOST_HAS_CATOPEN>). Если макрос описывает группу функций POSIX, то добавьте код boilerplate вдля автоматического обнаружения функции там, где это возможно (если вы задаетесь вопросом, почему мы не можем использовать макрос тестирования функций POSIX напрямую, помните, что многие из этих функций могут быть добавлены сторонними библиотеками, и поэтому не идентифицированы внутри<<unistd.h>>).

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

никогда не следует изменять, не меняйте этот файл.

включен по умолчанию, не добавляйте дополнительный код в этот файл, если вам не нужно. Если да, пожалуйста, не забудьте обновитьlibs/config/tools/configure.in.

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

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

Код выбора компилятора/платформы/стандартной библиотеки настроен так, что неизвестные платформы игнорируются и считаются полностью совместимыми со стандартами — это дает неизвестным платформам «спортивный шанс» работать «как есть» даже без запуска скрипта настройки.

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