Boost comes already configured for most common compilers and platforms; you
- should be able to use boost "as is". Since the compiler is configured
- separately from the standard library, the default configuration should work
- even if you replace the compiler's standard library with a third-party standard
- library (like STLport).
-
-
Using boost "as is" without trying to reconfigure is the recommended method for
- using boost. You can, however, run the configure script if you want to, and
- there are regression tests provided that allow you to test the current boost
- configuration with your particular compiler setup.
-
Boost library users can request support for additional compilers or platforms
- by visiting our Tracker
- and submitting a support request.
-
While Boost library users are not required to include that file directly, or
- use those configuration macros, such use is acceptable. The configuration
- macros are documented as to their purpose, usage, and limitations which makes
- them usable by both Boost library and user code.
+
Boost informational or helper
- macros are designed for use by Boost users as well as for our own internal
- use. Note however, that the feature test and
- defect test macros were designed for internal use by Boost libraries,
- not user code, so they can change at any time (though no gratuitous changes are
- made to them). Boost library problems resulting from changes to the
- configuration macros are caught by the Boost regression tests, so the Boost
- libraries are updated to account for those changes. By contrast, Boost library
- user code can be adversely affected by changes to the macros without warning.
- The best way to keep abreast of changes to the macros used in user code is to
- monitor the discussions on the Boost developers list.
Note: this configure script only sets up the Boost headers for
- use with a particular compiler. It has no effect on Boost.Build, or
- how the libraries are built.
-
If you know that boost is incorrectly configured for your particular setup, and
- you are on a UNIX like platform, then you may want to try and improve things by
- running the boost configure script. From a shell command prompt you will need
- to cd into <boost-root>/libs/config/ and type:
-
sh ./configure
-
you will see a list of the items being checked as the script works its way
- through the regression tests. Note that the configure script only really
- auto-detects your compiler if it's called g++, c++ or CC. If you are using some
- other compiler you will need to set one or more of the following environment
- variables:
-
-
-
Variable
-
-
Description
-
-
-
-
CXX
-
The name of the compiler, for example "c++".
-
-
-
CXXFLAGS
-
The compiler flags to use, for example "-O2".
-
-
-
LDFLAGS
-
The linker flags to use, for example "-L/mypath".
-
-
-
LIBS
-
Any libraries to link in, for example -lpthread.
-
-
-
For example to run the configure script with HP aCC, you might use something
- like:
However you run the configure script, when it finishes you will find a new
- header - user.hpp - located in the <boost-root/libs/config/> directory. Note
- that configure does not install this header into your boost include path by
- default. This header contains all the options generated by the
- configure script, plus a header-section that contains the user settable options
- from the default version of user.hpp (located
- under <boost-root>/boost/config/). There are two ways you can use this
- header:
-
Option 1: copy the header into <boost-root>/boost/config/ so that it
- replaces the default user.hpp provided
- by boost. This option allows only one configure-generated setup; boost
- developers should avoid this option, as it incurs the danger of accidentally
- committing a configure-modified user.hpp to the cvs repository (something you
- will not be thanked for!).
-
Option 2: give the header a more memorable name, and place it somewhere
- convenient; then, define the macro BOOST_USER_CONFIG to point to it. For
- example create a new sub-directory <boost-root>/boost/config/user/, and
- copy the header there; for example as "multithread-gcc-config.hpp". Then, when
- compiling add the command line option:
- -DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>", and
- boost will use the new configuration header. This option allows you to generate
- more than one configuration header, and to keep them separate from the boost
- source - so that updates to the source do not interfere with your
- configuration.
-
User settable options
-
There are some configuration-options that represent user choices, rather than
- compiler defects or platform specific options. These are listed in
- <boost/config/user.hpp> and at the start of a configure-generated
- user.hpp header. You can define these on the command line, or by editing
- <boost/config/user.hpp>, they are listed in the following table:
-
-
-
Macro
-
-
Description
-
-
-
-
BOOST_USER_CONFIG
-
When defined, it should point to the name of the user
- configuration file to include prior to any boost configuration files. When not
- defined, defaults to <boost/config/user.hpp>.
-
-
-
BOOST_COMPILER_CONFIG
-
When defined, it should point to the name of the
- compiler configuration file to use. Defining this cuts out the compiler
- selection logic, and eliminates the dependency on the header containing that
- logic. For example if you are using gcc, then you could define
- BOOST_COMPILER_CONFIG to "boost/config/compiler/gcc.hpp".
-
-
-
BOOST_STDLIB_CONFIG
-
When defined, it should point to the name of the
- standard library configuration file to use. Defining this cuts out the standard
- library selection logic, and eliminates the dependency on the header containing
- that logic. For example if you are using STLport, then you could define
- BOOST_STDLIB_CONFIG to "boost/config/stdlib/stlport.hpp".
-
-
-
BOOST_PLATFORM_CONFIG
-
When defined, it should point to the name of the
- platform configuration file to use. Defining this cuts out the platform
- selection logic, and eliminates the dependency on the header containing that
- logic. For example if you are compiling on linux, then you could define
- BOOST_PLATFORM_CONFIG to "boost/config/platform/linux.hpp".
-
-
-
BOOST_NO_COMPILER_CONFIG
-
When defined, no compiler configuration file is
- selected or included, define when the compiler is fully conformant with the
- standard, or where the user header (see BOOST_USER_CONFIG), has had any options
- necessary added to it, for example by an autoconf generated configure script.
-
-
-
BOOST_NO_STDLIB_CONFIG
-
When defined, no standard library configuration file
- is selected or included, define when the standard library is fully conformant
- with the standard, or where the user header (see BOOST_USER_CONFIG), has had
- any options necessary added to it, for example by an autoconf generated
- configure script.
-
-
-
BOOST_NO_PLATFORM_CONFIG
-
When defined, no platform configuration file is
- selected or included, define when the platform is fully conformant with the
- standard (and has no useful extra features), or where the user header (see
- BOOST_USER_CONFIG), has had any options necessary added to it, for example by
- an autoconf generated configure script.
-
-
-
BOOST_NO_CONFIG
-
Equivalent to defining all of
- BOOST_NO_COMPILER_CONFIG, BOOST_NO_STDLIB_CONFIG and BOOST_NO_PLATFORM_CONFIG.
-
-
-
BOOST_STRICT_CONFIG
-
The normal behavior for compiler versions that are newer than the last known
- version, is to assume that they have all the same defects as the last known
- version. By setting this define, then compiler versions that are newer than the
- last known version are assumed to be fully conforming with the standard. This
- is probably most useful for boost developers or testers, and for those who want
- to use boost to test beta compiler versions.
-
-
-
BOOST_ASSERT_CONFIG
-
When this flag is set, if the config finds anything unknown, then it will stop
- with a #error rather than continue. Boost regression testers should set this
- define, as should anyone who wants to quickly check whether boost is supported
- on their platform.
-
-
-
BOOST_DISABLE_THREADS
-
When defined, disables threading support, even if the
- compiler in its current translation mode supports multiple threads.
-
-
-
BOOST_DISABLE_WIN32
-
When defined, disables the use of Win32 specific API's, even when these are
- available. Also has the effect of setting BOOST_DISABLE_THREADS unless
- BOOST_HAS_PTHREADS is set. This option may be set automatically by the config
- system when it detects that the compiler is in "strict mode".
-
-
-
BOOST_DISABLE_ABI_HEADERS
-
Stops boost headers from including any prefix/suffix headers that normally
- control things like struct packing and alignment.
-
-
-
BOOST_ABI_PREFIX
-
A prefix header to include in place of whatever boost.config would normally
- select, any replacement should set up struct packing and alignment options as
- required.
-
-
-
BOOST_ABI_SUFFIX
-
A suffix header to include in place of whatever boost.config would normally
- select, any replacement should undo the effects of the prefix header.
-
-
-
BOOST_ALL_DYN_LINK
-
-
Forces all libraries that have separate source, to be linked as dll's rather
- than static libraries on Microsoft Windows (this macro is used to turn on
- __declspec(dllimport) modifiers, so that the compiler knows which symbols to
- look for in a dll rather than in a static library).
-
-
Note that there may be some libraries that can only be statically linked
- (Boost.Test for example) and others which may only be dynamically linked
- (Boost.Threads for example), in these cases this macro has no effect.
-
-
-
-
BOOST_WHATEVER_DYN_LINK
-
-
Forces library "whatever" to be linked as a dll rather than a static library on
- Microsoft Windows: replace the WHATEVER part of the macro name with the name of
- the library that you want to dynamically link to, for example use
- BOOST_DATE_TIME_DYN_LINK or BOOST_REGEX_DYN_LINK etc (this macro is used
- to turn on __declspec(dllimport) modifiers, so that the compiler knows which
- symbols to look for in a dll rather than in a static library).
-
-
Note that there may be some libraries that can only be statically linked
- (Boost.Test for example) and others which may only be dynamically linked
- (Boost.Threads for example), in these cases this macro is unsupported.
-
-
-
-
BOOST_ALL_NO_LIB
-
-
Tells the config system not to automatically select which libraries to link
- against.
-
-
Normally if a compiler supports #pragma lib, then the correct library build
- variant will be automatically selected and linked against, simply by the act of
- including one of that library's headers. This macro turns that feature
- off.
-
-
-
-
BOOST_WHATEVER_NO_LIB
-
-
Tells the config system not to automatically select which library to link
- against for library "whatever", replace WHATEVER in the macro name with the
- name of the library; for example BOOST_DATE_TIME_NO_LIB or
- BOOST_REGEX_NO_LIB.
-
-
Normally if a compiler supports #pragma lib, then the correct library build
- variant will be automatically selected and linked against, simply by the act of
- including one of that library's headers. This macro turns that feature
- off.
-
-
-
-
BOOST_LIB_DIAGNOSTIC
-
Causes the auto-linking code to output diagnostic messages indicating the name
- of the library that is selected for linking.
-
-
-
BOOST_LIB_TOOLSET
-
Overrides the name of the toolset part of the name of library being linked to;
- note if defined this must be defined to a quoted string literal, for example
- "abc".
-
-
-
Advanced configuration usage
-
By setting various macros on the compiler command line or by editing <boost/config/user.hpp>,
- the boost configuration setup can be optimised in a variety of ways.
-
-
Boost's configuration is structured so that the user-configuration is included
- first (defaulting to <boost/config/user.hpp>
- if BOOST_USER_CONFIG is not defined). This sets up any user-defined policies,
- and gives the user-configuration a chance to influence what happens next.
-
-
Next the compiler, standard library, and platform configuration files are
- included. These are included via macros (BOOST_COMPILER_CONFIG etc,
- see user settable macros), and if the corresponding macro is undefined
- then a separate header that detects which compiler/standard library/platform is
- in use is included in order to set these. The config can be told to ignore
- these headers altogether if the corresponding BOOST_NO_XXX macro is set (for
- example BOOST_NO_COMPILER_CONFIG to disable including any compiler
- configuration file - see user settable macros).
-
-
Finally the boost configuration header, includes <boost/config/suffix.hpp>;
- this header contains any boiler plate configuration code - for example where
- one boost macro being set implies that another must be set also.
-
The following usage examples represent just a few of the possibilities:
-
Example 1, creating our own frozen configuration.
-
Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0. Lets
- suppose also that we don't intend to update our compiler or standard library
- any time soon. In order to avoid breaking dependencies when we update boost, we
- may want to "freeze" our configuration headers, so that we only have to rebuild
- our project if the boost code itself has changed, and not because the boost
- config has been updated for more recent versions of Visual C++ or STLport.
- We'll start by realising that the configuration files in use are: <boost/config/compiler/visualc.hpp>
- for the compiler, <boost/config/stdlib/stlport.hpp>
- for the standard library, and <boost/config/platform/win32.hpp>
- for the platform. Next we'll create our own private configuration directory:
- boost/config/mysetup/, and copy the configuration files into there. Finally,
- open up <boost/config/user.hpp>
- and edit the following defines:
Now when you use boost, its configuration header will go straight to our
- "frozen" versions, and ignore the default versions, you will now be insulated
- from any configuration changes when you update boost. This technique is also
- useful if you want to modify some of the boost configuration files; for example
- if you are working with a beta compiler release not yet supported by boost.
-
Example 2: skipping files that you don't need.
-
Lets suppose that you're using boost with a compiler that is fully conformant
- with the standard; you're not interested in the fact that older versions of
- your compiler may have had bugs, because you know that your current version
- does not need any configuration macros setting. In a case like this, you can
- define BOOST_NO_COMPILER_CONFIG either on the command line, or in
- <boost/config/user.hpp>, and miss out the compiler configuration header
- altogether (actually you miss out two headers, one which works out what the
- compiler is, and one that configures boost for it). This has two consequences:
- the first is that less code has to be compiled, and the second that you have
- removed a dependency on two boost headers.
-
Example 3: using configure script to freeze the boost configuration.
-
If you are working on a unix-like platform then you can use the configure
- script to generate a "frozen" configuration based on your current compiler
- setup - see using the configure script for more
- details.
-
Testing the boost configuration
-
The boost configuration library provides a full set of regression test programs
- under the <boost-root>/libs/config/test/ sub-directory:
-
-
-
File
-
-
Description
-
-
-
-
config_info.cpp
-
Prints out a detailed description of your
- compiler/standard library/platform setup, plus your current boost
- configuration. The information provided by this program useful in setting up
- the boost configuration files. If you report that boost is incorrectly
- configured for your compiler/library/platform then please include the output
- from this program when reporting the changes required.
-
-
-
config_test.cpp
-
A monolithic test program that includes most of the
- individual test cases. This provides a quick check to see if boost is correctly
- configured for your compiler/library/platform.
-
-
-
limits_test.cpp
-
Tests your standard library's std::numeric_limits
- implementation (or its boost provided replacement if BOOST_NO_LIMITS is
- defined). This test file fails with most versions of numeric_limits, mainly due
- to the way that some compilers treat NAN's and infinity.
-
-
-
no_*pass.cpp
-
Individual compiler defect test files. Each of these
- should compile, if one does not then the corresponding BOOST_NO_XXX macro needs
- to be defined - see each test file for specific details.
-
-
-
no_*fail.cpp
-
Individual compiler defect test files. Each of these
- should not compile, if one does then the corresponding BOOST_NO_XXX
- macro is defined when it need not be - see each test file for specific details.
-
-
-
has_*pass.cpp
-
Individual feature test files. If one of these does not
- compile then the corresponding BOOST_HAS_XXX macro is defined when it should
- not be - see each test file for specific details.
-
-
-
has_*fail.cpp
-
Individual feature test files. If one of these does
- compile then the corresponding BOOST_HAS_XXX macro can be safely defined - see
- each test file for specific details.
-
-
-
Although you can run the configuration regression tests as individual test
- files, there are rather a lot of them, so there are a couple of shortcuts to
- help you out:
-
If you have built the boost regression test
- driver, then you can use this to produce a nice html formatted report of
- the results using the supplied test file.
-
Alternatively you can run the configure script like this:
-
./configure --enable-test
-
in which case the script will test the current configuration rather than
- creating a new one from scratch.
-
If you are reporting the results of these tests for a new
- platform/library/compiler then please include a log of the full compiler
- output, the output from config_info.cpp, and the pass/fail test results.
-
Boost Macro Reference
-
Macros that describe defects:
-
The following macros all describe features that are required by the C++
- standard, if one of the following macros is defined, then it represents a
- defect in the compiler's conformance with the standard.
-
-
-
Macro
-
-
Section
-
-
Description
-
-
-
-
BOOST_BCB_PARTIAL_SPECIALIZATION_BUG
-
Compiler
-
The compiler exibits certain partial specialisation bug - probably Borland C++
- Builder specific.
-
-
-
BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
-
Compiler
-
Argument dependent lookup fails if there is a using
- declaration for the symbol being looked up in the current scope. For
- example, using boost::get_pointer; prevents ADL from finding
- overloads of get_pointer in namespaces nested inside boost (but
- not elsewhere). Probably Borland specific.
-
-
-
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
-
Compiler
-
Compiler does not implement argument-dependent lookup
- (also named Koenig lookup); see std::3.4.2 [basic.koenig.lookup]
-
-
-
BOOST_NO_AUTO_PTR
-
Standard library
-
If the compiler / library supplies non-standard or
- broken std::auto_ptr.
-
-
-
BOOST_NO_CTYPE_FUNCTIONS
-
Platform
-
The Platform does not provide functions for the
- character-classifying operations <ctype.h> and <cctype>, only
- macros.
-
-
-
BOOST_NO_CV_SPECIALIZATIONS
-
Compiler
-
If template specialisations for cv-qualified types
- conflict with a specialisation for a cv-unqualififed type.
-
-
-
BOOST_NO_CV_VOID_SPECIALIZATIONS
-
Compiler
-
If template specialisations for cv-void types
- conflict with a specialisation for void.
-
-
-
BOOST_NO_CWCHAR
-
Platform
-
The Platform does not provide <wchar.h> and
- <cwchar>.
-
-
-
BOOST_NO_CWCTYPE
-
Platform
-
The Platform does not provide <wctype.h> and
- <cwctype>.
-
-
-
BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
-
Compiler
-
The compiler fails to compile a nested class that has
- a dependent base class:
template<typename T>
-struct foo : {
- template<typename U>
- struct bar : public U {};
-};
Template value parameters cannot have a dependent
- type, for example:
template<class T, typename T::type value>
-class X { ... };
-
-
-
-
BOOST_NO_EXCEPTION_STD_NAMESPACE
-
Standard Library
-
The standard library does not put some or all of the contents of
- <exception> in namespace std.
-
-
-
BOOST_NO_EXCEPTIONS
-
Compiler
-
The compiler does not support exception handling (this setting is typically
- required by many C++ compilers for embedded platforms). Note that there is no
- requirement for boost libraries to honor this configuration setting - indeed
- doing so may be impossible in some cases. Those libraries that do honor this
- will typically abort if a critical error occurs - you have been warned!
-
-
-
BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
-
Compiler
-
Can only use deduced template arguments when calling
- function template instantiations.
-
-
-
BOOST_NO_FUNCTION_TEMPLATE_ORDERING
-
Compiler
-
The compiler does not perform function template
- ordering or its function template ordering is incorrect.
-
The C++ implementation does not provide wchar_t, or
- it is really a synonym for another integral type. Use this symbol to decide
- whether it is appropriate to explicitly specialize a template on wchar_t if
- there is already a specialization for other integer types.
-
-
-
BOOST_NO_IS_ABSTRACT
-
Compiler
-
The C++ compiler does not support SFINAE with
- abstract types, this is covered by
- Core Language DR337, but is not part of the current standard.
- Fortunately most compilers that support SFINAE also support this DR.
-
-
-
BOOST_NO_LIMITS
-
Standard library
-
The C++ implementation does not provide the
- <limits> header. Never check for this symbol in library code; always
- include <boost/limits.hpp>, which guarantees to provide std::numeric_limits.
-
-
-
BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
-
Standard library
-
Constants such as numeric_limits<T>::is_signed
- are not available for use at compile-time.
-
-
-
BOOST_NO_LONG_LONG_NUMERIC_LIMITS
-
Standard library
-
There is no specialization for numeric_limits<long long> and
- numeric_limits<unsigned long long>. <boost/limits.hpp> will then
- add these specializations as a standard library "fix" only if the compiler
- supports the long long datatype.
-
-
-
BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS
-
Compiler
-
The compiler does not support the specialization of individual member
- functions of template classes.
-
-
-
BOOST_NO_MEMBER_TEMPLATE_KEYWORD
-
Compiler
-
If the compiler supports member templates, but not
- the template keyword when accessing member template classes.
-
-
-
BOOST_NO_MEMBER_TEMPLATE_FRIENDS
-
Compiler
-
Member template friend syntax ("template<class
- P> friend class frd;") described in the C++ Standard, 14.5.3, not supported.
-
-
-
BOOST_NO_MEMBER_TEMPLATES
-
Compiler
-
Member template functions not fully supported.
-
-
-
BOOST_NO_MS_INT64_NUMERIC_LIMITS
-
Standard library
-
There is no specialization for numeric_limits<__int64> and
- numeric_limits<unsigned __int64>. <boost/limits.hpp> will then add
- these specializations as a standard library "fix", only if the compiler
- supports the __int64 datatype.
-
-
-
BOOST_NO_OPERATORS_IN_NAMESPACE
-
Compiler
-
Compiler requires inherited operator friend functions
- to be defined at namespace scope, then using'ed to boost. Probably GCC
- specific. See boost/operators.hpp for
- example.
-
-
-
BOOST_NO_POINTER_TO_MEMBER_CONST
-
Compiler
-
The compiler does not correctly handle pointers to
- const member functions, preventing use of these in overloaded function
- templates. See boost/functional.hpp for
- example.
-
-
-
BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
-
Compiler
-
Pointers to members don't work when used as template
- parameters.
-
-
-
BOOST_NO_PRIVATE_IN_AGGREGATE
-
Compiler
-
The compiler misreads 8.5.1, treating classes as
- non-aggregate if they contain private or protected member functions.
-
-
-
BOOST_NO_SFINAE
-
Compiler
-
The compiler does not support the "Substitution
- Failure Is Not An Error" meta-programming idiom.
-
-
-
BOOST_NO_STD_ALLOCATOR
-
Standard library
-
The C++ standard library does not provide a standards
- conforming std::allocator.
-
-
-
BOOST_NO_STD_DISTANCE
-
Standard library
-
The platform does not have a conforming version of
- std::distance.
-
-
-
BOOST_NO_STD_ITERATOR
-
Standard library
-
The C++ implementation fails to provide the
- std::iterator class.
-
-
-
BOOST_NO_STD_ITERATOR_TRAITS
-
Standard library
-
The compiler does not provide a standard compliant
- implementation of std::iterator_traits. Note that the compiler may still have a
- non-standard implementation.
-
-
-
BOOST_NO_STD_LOCALE
-
Standard library
-
The standard library lacks std::locale.
-
-
-
BOOST_NO_STD_MESSAGES
-
Standard library
-
The standard library lacks a conforming std::messages
- facet.
-
-
-
BOOST_NO_STD_MIN_MAX
-
Standard library
-
The C++ standard library does not provide the min()
- and max() template functions that should be in <algorithm>.
-
-
-
BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN
-
Standard library
-
Defined if the standard library's output iterators are not
- assignable.
-
-
-
BOOST_NO_STD_USE_FACET
-
Standard library
-
The standard library lacks a conforming
- std::use_facet.
-
-
-
BOOST_NO_STD_WSTREAMBUF
-
Standard library
-
The standard library's implementation of std::basic_streambuf<wchar_t>
- is either missing, incomplete, or buggy.
-
-
-
BOOST_NO_STD_WSTRING
-
Standard library
-
The standard library lacks std::wstring.
-
-
-
BOOST_NO_STDC_NAMESPACE
-
Compiler/Platform
-
The contents of C++ standard headers for C library
- functions (the <c...> headers) have not been placed in namespace std.
- This test is difficult - some libraries "fake" the std C functions by adding
- using declarations to import them into namespace std, unfortunately they don't
- necessarily catch all of them...
-
-
-
BOOST_NO_STRINGSTREAM
-
Standard library
-
The C++ implementation does not provide the
- <sstream> header.
-
-
-
BOOST_NO_SWPRINTF
-
Platform
-
The platform does not have a conforming version of
- swprintf.
-
-
-
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
-
Compiler
-
Class template partial specialization (14.5.4
- [temp.class.spec]) not supported.
-
-
-
BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS
-
Standard library
-
The standard library does not provide templated
- iterator constructors for its containers.
-
-
-
BOOST_NO_TEMPLATE_TEMPLATES
-
Compiler
-
The compiler does not support template template parameters.
-
-
-
BOOST_NO_UNREACHABLE_RETURN_DETECTION
-
Compiler
-
If a return is unreachable, then no return statement should be required,
- however some compilers insist on it, while other issue a bunch of warnings if
- it is in fact present.
The compiler will not accept a using
- declaration that brings a function from a typename used as a base
- class into a derived class if functions of the same name are present
- in the derived class.
-
-
-
BOOST_NO_USING_TEMPLATE
-
Compiler
-
The compiler will not accept a using declaration that
- imports a template class or function from another namespace. Originally a
- Borland specific problem with imports to/from the global namespace, extended to
- MSVC6 which has a specific issue with importing template classes (but not
- functions).
-
-
-
BOOST_NO_VOID_RETURNS
-
Compiler
-
The compiler does not allow a void function to return
- the result of calling another void function.
-
void f() {}
-void g() { return f(); }
-
-
-
-
Macros that describe optional features:
-
The following macros describe features that are not required by the C++
- standard. The macro is only defined if the feature is present.
-
-
-
Macro
-
-
Section
-
-
Description
-
-
-
-
BOOST_HAS_BETHREADS
-
Platform
-
The platform supports BeOS style threads.
-
-
-
BOOST_HAS_CLOCK_GETTIME
-
Platform
-
The platform has the POSIX API clock_gettime.
-
-
-
BOOST_HAS_DECLSPEC
-
-
Compiler
-
The compiler uses __declspec(dllexport) and __declspec(dllimport) to
- export/import symbols from dll's.
-
-
-
BOOST_HAS_DIRENT_H
-
Platform
-
The platform has the POSIX header <dirent.h>.
-
-
-
BOOST_HAS_EXPM1
-
Platform
-
The platform has the functions expm1 expm1f and expm1l in <math.h>
-
-
-
BOOST_HAS_FTIME
-
Platform
-
The platform has the Win32 API GetSystemTimeAsFileTime.
-
-
-
BOOST_HAS_GETTIMEOFDAY
-
Platform
-
The platform has the POSIX API gettimeofday.
-
-
-
BOOST_HAS_HASH
-
Standard library
-
The C++ implementation provides the (SGI) hash_set
- and hash_map classes. When defined, BOOST_HASH_SET_HEADER and
- BOOST_HASH_LIST_HEADER will contain the names of the header needed to access
- hash_set and hash_map; BOOST_STD_EXTENSION_NAMESPACE will provide the namespace
- in which the two class templates reside.
-
-
-
BOOST_HAS_LOG1P
-
Platform
-
The platform has the functions log1p, log1pf and
- log1pl in <math.h>.
-
-
-
BOOST_HAS_LONG_LONG
-
Compiler
-
The compiler supports the long long data type.
-
-
-
BOOST_HAS_MACRO_USE_FACET
-
Standard library
-
The standard library lacks a conforming
- std::use_facet, but has a macro _USE(loc, Type) that does the job. This is
- primarily for the Dinkumware std lib.
-
-
-
BOOST_HAS_MS_INT64
-
Compiler
-
The compiler supports the __int64 data type.
-
-
-
BOOST_HAS_NANOSLEEP
-
Platform
-
The platform has the POSIX API nanosleep.
-
-
-
BOOST_HAS_NL_TYPES_H
-
Platform
-
The platform has an <nl_types.h>.
-
-
-
BOOST_HAS_NRVO
-
Compiler
-
Indicated that the compiler supports the named return value optimization
- (NRVO). Used to select the most efficient implementation for some function. See
- boost/operators.hpp for example.
-
-
-
BOOST_HAS_PARTIAL_STD_ALLOCATOR
-
Standard Library
-
The standard library has a partially conforming std::allocator class, but
- without any of the member templates.
-
-
-
BOOST_HAS_PTHREAD_DELAY_NP
-
Platform
-
The platform has the POSIX API pthread_delay_np.
-
-
-
BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
-
Platform
-
The platform has the POSIX API pthread_mutexattr_settype.
-
-
-
BOOST_HAS_PTHREAD_YIELD
-
Platform
-
The platform has the POSIX API pthread_yield.
-
-
-
BOOST_HAS_PTHREADS
-
Platform
-
The platform support POSIX style threads.
-
-
-
BOOST_HAS_SCHED_YIELD
-
Platform
-
The platform has the POSIX API sched_yield.
-
-
-
BOOST_HAS_SGI_TYPE_TRAITS
-
Compiler/standard library
-
The compiler has native support for SGI style type traits.
-
-
-
BOOST_HAS_STDINT_H
-
Platform
-
The platform has a <stdint.h>
-
-
-
BOOST_HAS_SLIST
-
Standard library
-
The C++ implementation provides the (SGI) slist
- class. When defined, BOOST_SLIST_HEADER will contain the name of the header
- needed to access slist and BOOST_STD_EXTENSION_NAMESPACE will provide the
- namespace in which slist resides.
-
-
-
BOOST_HAS_STLP_USE_FACET
-
Standard library
-
The standard library lacks a conforming
- std::use_facet, but has a workaround class-version that does the job. This is
- primarily for the STLport std lib.
-
-
-
BOOST_HAS_TR1_ARRAY
-
Standard library
-
The library has a TR1 conforming version of
- <array>
-
-
-
BOOST_HAS_TR1_COMPLEX_OVERLOADS
-
Standard library
-
The library has a version of <complex> that
- supports passing scalars to the complex number algorithms.
-
-
-
BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG
-
Standard library
-
The library has a version of <complex> that
- includes the new inverse trig functions from TR1.
-
-
-
BOOST_HAS_TR1_REFERENCE_WRAPPER
-
Standard library
-
The library has TR1 conforming reference wrappers in
- <functional>.
-
-
-
BOOST_HAS_TR1_RESULT_OF
-
Standard library
-
The library has a TR1 conforming result_of template
- in <functional>.
-
-
-
BOOST_HAS_TR1_MEM_FN
-
Standard library
-
The library has a TR1 conforming mem_fn function
- template in <functional>.
-
-
-
BOOST_HAS_TR1_BIND
-
Standard library
-
The library has a TR1 conforming bind function
- template in <functional>.
-
-
-
BOOST_HAS_TR1_FUNCTION
-
Standard library
-
The library has a TR1 conforming function
- class template in <functional>.
-
-
-
BOOST_HAS_TR1_HASH
-
Standard library
-
The library has a TR1 conforming hash function
- template in <functional>.
-
-
-
BOOST_HAS_TR1_SHARED_PTR
-
Standard library
-
The library has a TR1 conforming shared_ptr
- class template in <memory>.
-
-
-
BOOST_HAS_TR1_RANDOM
-
Standard library
-
The library has a TR1 conforming version of
- <random>.
-
-
-
BOOST_HAS_TR1_REGEX
-
Standard library
-
The library has a TR1 conforming version of
- <regex>.
-
-
-
BOOST_HAS_TR1_TUPLE
-
Standard library
-
The library has a TR1 conforming version of
- <tuple>.
-
-
-
BOOST_HAS_TR1_TYPE_TRAITS
-
Standard library
-
The library has a TR1 conforming version of
- <type_traits>.
-
-
-
BOOST_HAS_TR1_UTILITY
-
Standard library
-
The library has the TR1 additions to <utility>
- (tuple interface to std::pair).
-
-
-
BOOST_HAS_TR1_UNORDERED_MAP
-
Standard library
-
The library has a TR1 conforming version of
- <unordered_map>.
-
-
-
BOOST_HAS_TR1_UNORDERED_SET
-
Standard library
-
The library has a TR1 conforming version of
- <unordered_set>.
-
-
-
BOOST_HAS_TR1
-
Standard library
-
Implies all the other BOOST_HAS_TR1_* macros should
- be set.
-
-
-
BOOST_HAS_THREADS
-
Platform/compiler
-
Defined if the compiler, in its current translation
- mode, supports multiple threads of execution.
-
-
-
BOOST_HAS_TWO_ARG_USE_FACET
-
Standard library
-
The standard library lacks a conforming
- std::use_facet, but has a two argument version that does the job. This is
- primarily for the Rogue Wave std lib.
-
-
-
BOOST_HAS_UNISTD_H
-
Platform
-
The Platform provides <unistd.h>.
-
-
-
BOOST_HAS_WINTHREADS
-
Platform
-
The platform supports MS Windows style threads.
-
-
-
BOOST_MSVC_STD_ITERATOR
-
Standard library
-
Microsoft's broken version of std::iterator is being
- used. This implies that std::iterator takes no more than two template
- parameters.
-
-
-
BOOST_MSVC6_MEMBER_TEMPLATES
-
Compiler
-
Microsoft Visual C++ 6.0 has enough member template
- idiosyncrasies (being polite) that BOOST_NO_MEMBER_TEMPLATES is defined for
- this compiler. BOOST_MSVC6_MEMBER_TEMPLATES is defined to allow compiler
- specific workarounds. This macro gets defined automatically if
- BOOST_NO_MEMBER_TEMPLATES is not defined - in other words this is treated as a
- strict subset of the features required by the standard.
-
-
-
BOOST_HAS_STDINT_H
-
Platform
-
There are no 1998 C++ Standard headers
- <stdint.h> or <cstdint>, although the 1999 C Standard does include
- <stdint.h>. If <stdint.h> is present, <boost/stdint.h> can
- make good use of it, so a flag is supplied (signalling presence; thus the
- default is not present, conforming to the current C++ standard).
-
-
-
Boost Helper Macros
-
The following macros are either simple helpers, or macros that provide
- workarounds for compiler/standard library defects.
-
-
-
Macro
-
-
Description
-
-
-
-
BOOST_DEDUCED_TYPENAME
-
Some compilers don't support the use of typename
- for dependent types in deduced contexts. This macro expands to nothing on those
- compilers, and typename elsewhere. For example, replace:
The header to include to get the SGI hash_map class. This macro is only
- available if BOOST_HAS_HASH is defined.
-
-
-
BOOST_HASH_SET_HEADER
-
The header to include to get the SGI hash_set class. This macro is only
- available if BOOST_HAS_HASH is defined.
-
-
-
BOOST_SLIST_HEADER
-
The header to include to get the SGI slist class. This macro is only available
- if BOOST_HAS_SLIST is defined.
-
-
-
BOOST_STD_EXTENSION_NAMESPACE
-
The namespace used for std library extensions (hashtable classes etc).
-
-
-
BOOST_STATIC_CONSTANT(Type, assignment)
-
On compilers which don't allow in-class
- initialization of static integral constant members, we must use enums as a
- workaround if we want the constants to be available at compile-time. This macro
- gives us a convenient way to declare such constants. For example instead of:
struct foo{
- static const int value = 2;
-};
-
use:
-
struct foo{
- BOOST_STATIC_CONSTANT(int, value = 2);
-};
-
-
-
-
BOOST_UNREACHABLE_RETURN(result)
-
Normally evaluates to nothing, but evaluates to return
- x; if the compiler requires a return, even when it can never be
- reached.
Some compilers silently "fold" different function template instantiations if
- some of the template parameters don't appear in the function parameter list.
- For instance:
-
- incorrectly outputs "2 2 double double " on VC++ 6. These macros, to
- be used in the function parameter list, fix the problem without effects on the
- calling syntax. For instance, in the case above write:
-
- Beware that they can declare (for affected compilers) a dummy defaulted parameter,
- so they
-
-
- a) should be always invoked *at the end* of the parameter list
-
- b) can't be used if your function template is multiply declared.
-
-
- Furthermore, in order to add any needed comma separator, an "APPEND_*" version
- must be used when the macro invocation appears after a normal parameter
- declaration or after the invocation of another macro of this same group.
-
-
-
-
BOOST_USE_FACET(Type, loc)
-
When the standard library does not have a comforming
- std::use_facet there are various workarounds available, but they differ from
- library to library. This macro provides a consistent way to access a locale's
- facets. For example, replace:
std::use_facet<Type>(loc);
-
with:
-
BOOST_USE_FACET(Type, loc);
-
Note do not add a std:: prefix to the front of BOOST_USE_FACET.
-
-
-
-
BOOST_HAS_FACET(Type, loc)
-
When the standard library does not have a comforming
- std::has_facet there are various workarounds available, but they differ from
- library to library. This macro provides a consistent way to check a locale's
- facets. For example, replace:
std::has_facet<Type>(loc);
-
with:
-
BOOST_HAS_FACET(Type, loc);
-
Note do not add a std:: prefix to the front of BOOST_HAS_FACET.
-
-
-
-
BOOST_NESTED_TEMPLATE
-
Member templates are supported by some compilers even
- though they can't use the A::template member<U> syntax, as a workaround
- replace:
Converts the parameter X to a string after macro
- replacement on X has been performed.
-
-
-
BOOST_JOIN(X,Y)
-
This piece of macro magic joins the two arguments
- together, even when one of the arguments is itself a macro (see 16.3.1 in C++
- standard). This is normally used to create a mangled name in combination with a
- predefined macro such a __LINE__.
-
-
-
Boost Informational Macros
-
The following macros describe boost features; these are, generally speaking the
- only boost macros that should be tested in user code.
-
-
-
Macro
-
-
Header
-
-
Description
-
-
-
-
BOOST_VERSION
-
<boost/version.hpp>
-
Describes the boost version number in XXYYZZ format
- such that: (BOOST_VERSION % 100) is the sub-minor version, ((BOOST_VERSION /
- 100) % 1000) is the minor version, and (BOOST_VERSION / 100000) is the major
- version.
-
-
-
BOOST_NO_INT64_T
-
<boost/cstdint.hpp>
<boost/stdint.h>
-
-
Defined if there are no 64-bit integral types:
- int64_t, uint64_t etc.
-
-
-
BOOST_NO_INTEGRAL_INT64_T
-
<boost/cstdint.hpp>
<boost/stdint.h>
-
-
Defined if int64_t as defined by
- <boost/cstdint.hpp> is not usable in integral constant expressions.
-
-
-
BOOST_MSVC
-
<boost/config.hpp>
-
Defined if the compiler is really Microsoft Visual C++, as
- opposed to one of the many other compilers that also define _MSC_VER.
-
-
-
BOOST_INTEL
-
<boost/config.hpp>
-
Defined if the compiler is an Intel compiler, takes the same
- value as the compiler version macro.
-
-
-
BOOST_WINDOWS
-
<boost/config.hpp>
-
Defined if the Windows platfrom API is available.
-
-
-
BOOST_DINKUMWARE_STDLIB
-
<boost/config.hpp>
-
Defined if the dinkumware standard library is in use, takes the same value as
- the Dinkumware library version macro _CPPLIB_VER if defined, otherwise 1.
-
-
-
BOOST_NO_WREGEX
-
<boost/regex.hpp>
-
Defined if the regex library does not support wide
- character regular expressions.
-
-
-
BOOST_COMPILER
-
<boost/config.hpp>
-
Defined as a string describing the name and version
- number of the compiler in use. Mainly for debugging the configuration.
-
-
-
BOOST_STDLIB
-
<boost/config.hpp>
-
Defined as a string describing the name and version
- number of the standard library in use. Mainly for debugging the configuration.
-
-
-
BOOST_PLATFORM
-
<boost/config.hpp>
-
Defined as a string describing the name of the
- platform. Mainly for debugging the configuration.
-
-
-
-
Macros for libraries with separate source code
-
The following macros and helper headers are of use to authors whose libraries
- include separate source code, and are intended to address two issues: fixing
- the ABI of the compiled library, and selecting which compiled library to link
- against based upon the compilers settings.
-
ABI Fixing
-
When linking against a pre-compiled library it vital that the ABI used by the
- compiler when building the library matchesexactly the ABI
- used by the code using the library. In this case ABI means things like
- the struct packing arrangement used, the name mangling scheme used, or the size
- of some types (enum types for example). This is separate from things like
- threading support, or runtime library variations, which have to be dealt with
- by build variants. To put this in perspective there is one compiler
- (Borland's) that has so many compiler options that make subtle changes to the
- ABI, that at least in theory there 3200 combinations, and that's without
- considering runtime library variations. Fortunately these variations can
- be managed by #pragma's that tell the compiler what ABI to use for the types
- declared in your library. In order to avoid sprinkling #pragma's all over the
- boost headers, there are some prefix and suffix headers that do the job.
- Typical usage is:
-
my_library.cpp
-
-
#ifndef MY_INCLUDE_GUARD
-#define MY_INCLUDE_GUARD
-
-// all includes go here:
-#include <boost/config.hpp>
-#include <whatever>
-
-#include <boost/config/abi_prefix.hpp> // must be the last #include
-
-namespace boost{
-// your code goes here
-}
-
-#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas
-
-#endif // include guard
-
-
-
my_library.cpp
-
-
...
-// nothing special need be done in the implementation file
-...
-
-
The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS, or
- they can define BOOST_ABI_PREFIX and/or BOOST_ABI_SUFFIX to point to their own
- prefix/suffix headers if they so wish.
-
Automatic library selection
-
It is essential that users link to a build of a library which was built against
- the same runtime library that their application will be built against - if this
- does not happen then the library will not be binary compatible with their own
- code - and there is a high likelihood that their application will
- experience runtime crashes. These kinds of problems can be extremely
- time consuming and difficult to debug, and often lead to frustrated users and
- authors alike (simply selecting the right library to link against is not as
- easy as it seems when their are 6-8 of them to chose from, and some users seem
- to be blissfully unaware that there even are different runtimes available to
- them).
-
To solve this issue, some compilers allow source code to contain #pragma's that
- instruct the linker which library to link against, all the user need do is
- include the headers they need, place the compiled libraries in their library
- search path, and the compiler and linker do the rest. Boost.config
- supports this via the header <boost/config/auto_link.hpp>, before
- including this header one or more of the following macros need to be defined:
-
-
-
BOOST_LIB_NAME
-
- Required: An identifier containing the basename of the library, for
- example 'boost_regex'.
-
-
-
BOOST_DYN_LINK
-
Optional: when set link to dll rather than static library.
-
-
-
BOOST_LIB_DIAGNOSTIC
-
Optional: when set the header will print out the name of the library selected
- (useful for debugging).
-
-
-
If the compiler supports this mechanism, then it will be told to link against
- the appropriately named library, the actual algorithm used to mangle the name
- of the library is documented inside <boost/config/auto_link.hpp> and has
- to match that used to create the libraries via bjam 's install rules.
-
Typical usage is:
-
my_library.hpp
-
-
...
-//
-// Don't include auto-linking code if the user has disabled it by
-// defining BOOST_ALL_NO_LIB, or BOOST_MY_LIBRARY_NO_LIB, or if this
-// is one of our own source files (signified by BOOST_MY_LIBRARY_SOURCE):
-//
-#if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_MY_LIBRARY_NO_LIB) && !defined(BOOST_MY_LIBRARY_SOURCE)
-# define BOOST_LIB_NAME boost_my_library
-# ifdef BOOST_MY_LIBRARY_DYN_LINK
-# define BOOST_DYN_LINK
-# endif
-# include <boost/config/auto_link.hpp>
-#endif
-...
-
-
-
my_library.cpp
-
-
// define BOOST_MY_LIBRARY_SOURCE so that the header knows that the
-// library is being built (possibly exporting rather than importing code)
-//
-#define BOOST_MY_LIBRARY_SOURCE
-
-#include <boost/my_library/my_library.hpp>
-...
-
-
Guidelines for Boost Authors
-
The boost/config.hpp header is used to
- pass configuration information to other boost files, allowing them to cope with
- platform dependencies such as arithmetic byte ordering, compiler pragmas, or
- compiler shortcomings. Without such configuration information, many current
- compilers would not work with the Boost libraries.
-
Centralizing configuration information in this header reduces the number of
- files that must be modified when porting libraries to new platforms, or when
- compilers are updated. Ideally, no other files would have to be modified when
- porting to a new platform.
-
Configuration headers are controversial because some view them as condoning
- broken compilers and encouraging non-standard subsets. Adding settings for
- additional platforms and maintaining existing settings can also be a problem.
- In other words, configuration headers are a necessary evil rather than a
- desirable feature. The boost config.hpp policy is designed to minimize the
- problems and maximize the benefits of a configuration header.
-
Note that:
-
-
- Boost library implementers are not required to #include
- <boost/config.hpp>, and are not required in any way to support compilers
- that do not comply with the C++ Standard (ISO/IEC 14882).
-
- If a library implementer wishes to support some non-conforming compiler, or to
- support some platform specific feature, #include <boost/config.hpp> is
- the preferred way to obtain configuration information not available from the
- standard headers such as <climits>, etc.
-
- If configuration information can be deduced from standard headers such as
- <climits>, use those standard headers rather than
- <boost/config.hpp>.
-
- Boost files that use macros defined in <boost/config.hpp> should have
- sensible, standard conforming, default behavior if the macro is not defined.
- This means that the starting point for porting <boost/config.hpp> to a
- new platform is simply to define nothing at all specific to that platform. In
- the rare case where there is no sensible default behavior, an #error message
- should describe the problem.
-
- If a Boost library implementer wants something added to config.hpp, post a
- request on the Boost mailing list. There is no guarantee such a request will be
- honored; the intent is to limit the complexity of config.hpp.
-
- The intent is to support only compilers which appear on their way to becoming
- C++ Standard compliant, and only recent releases of those compilers at that.
-
- The intent is not to disable mainstream features now well-supported by the
- majority of compilers, such as namespaces, exceptions, RTTI, or templates.
-
-
-
Adding New Defect Macros
-
When you need to add a new defect macro - either to fix a problem with an
- existing library, or when adding a new library - distil the issue down to a
- simple test case; often, at this point other (possibly better) workarounds may
- become apparent. Secondly always post the test case code to the boost mailing
- list and invite comments; remember that C++ is complex and that sometimes what
- may appear a defect, may in fact turn out to be a problem with the authors
- understanding of the standard.
-
When you name the macro, follow the BOOST_NO_SOMETHING naming convention, so
- that it's obvious that this is a macro reporting a defect.
-
Finally, add the test program to the regression tests. You will need to place
- the test case in a .ipp file with the following comments near the top:
-
// MACRO: BOOST_NO_FOO
-// TITLE: foo
-// DESCRIPTION: If the compiler fails to support foo
-
These comments are processed by the autoconf script, so make sure the format
- follows the one given. The file should be named "boost_no_foo.ipp", where foo
- is the defect description - try and keep the file name under the Mac 30
- character filename limit though. You will also need to provide a function
- prototype "int test()" that is declared in a namespace with the same name as
- the macro, but in all lower case, and which returns zero on success:
- Once the test code is in place, build and run the program "generate.cpp" that
- you will find in the boost-root/libs/config/tools/ directory. This generates
- two .cpp test files from the new test code, and adds the tests to the
- regression test Jamfile, and the config_test.cpp test program. Finally add a
- new entry to config_info.cpp so that the new macro gets printed out when that
- program is run.
-
Adding New Feature Test Macros
-
When you need to add a macro that describes a feature that the standard does
- not require, follow the convention for adding a new defect macro (above), but
- call the macro BOOST_HAS_FOO, and name the test file "boost_has_foo.ipp". Try
- not to add feature test macros unnecessarily, if there is a platform specific
- macro that can already be used (for example _WIN32, __BEOS__, or __linux) to
- identify the feature then use that. Try to keep the macro to a feature group,
- or header name, rather than one specific API (for example BOOST_HAS_NL_TYPES_H
- rather than BOOST_HAS_CATOPEN). If the macro describes a POSIX feature group,
- then add boilerplate code to boost/config/suffix.hpp
- to auto-detect the feature where possible (if you are wondering why we can't
- use POSIX feature test macro directly, remember that many of these features can
- be added by third party libraries, and are not therefore identified inside
- <unistd.h>).
-
Modifying the Boost Configuration Headers
-
The aim of boost's configuration setup is that the configuration headers should
- be relatively stable - a boost user should not have to recompile their code
- just because the configuration for some compiler that they're not interested in
- has changed. Separating the configuration into separate compiler/standard
- library/platform sections provides for part of this stability, but boost
- authors require some amount of restraint as well, in particular:
-
<boost/config.hpp> should never
- change, don't alter this file.
<boost/config/suffix.hpp> is
- always included so be careful about modifying this file as it breaks
- dependencies for everyone. This file should include only "boilerplate"
- configuration code, and generally should change only when new macros are added.
The compiler/platform/standard library selection code is set up so that unknown
- platforms are ignored and assumed to be fully standards compliant - this gives
- unknown platforms a "sporting chance" of working "as is" even without running
- the configure script.
-
When adding or modifying the individual mini-configs, assume that future, as
- yet unreleased versions of compilers, have all the defects of the current
- version. Although this is perhaps unnecessarily pessimistic, it cuts down on
- the maintenance of these files, and experience suggests that pessimism is
- better placed than optimism here!
-
Rationale
-
The problem with many traditional "textbook" implementations of configuration
- headers (where all the configuration options are in a single "monolithic"
- header) is that they violate certain fundamental software engineering
- principles which would have the effect of making boost more fragile, more
- difficult to maintain and more difficult to use safely. You can find a
- description of the principles from the
- following article.
-
The problem
-
Consider a situation in which you are concurrently developing on multiple
- platforms. Then consider adding a new platform or changing the platform
- definitions of an existing platform. What happens? Everything, and this does
- literally mean everything, recompiles. Isn't it quite absurd that adding a new
- platform, which has absolutely nothing to do with previously existing
- platforms, means that all code on all existing platforms needs to be
- recompiled?
-
Effectively, there is an imposed physical dependency between platforms that
- have nothing to do with each other. Essentially, the traditional solution
- employed by configuration headers does not conform to the Open-Closed
- Principle:
-
"A module should be open for extension but closed for modification."
-
Extending a traditional configuration header implies modifying existing code.
-
Furthermore, consider the complexity and fragility of the platform detection
- code. What if a simple change breaks the detection on some minor platform? What
- if someone accidentally or on purpose (as a workaround for some other problem)
- defines some platform dependent macros that are used by the detection code? A
- traditional configuration header is one of the most volatile headers of the
- entire library, and more stable elements of Boost would depend on it. This
- violates the Stable Dependencies Principle:
-
"Depend in the direction of stability."
-
After even a minor change to a traditional configuration header on one minor
- platform, almost everything on every platform should be tested if we follow
- sound software engineering practice.
-
Another important issue is that it is not always possible to submit changes to
- <boost/config.hpp>. Some boost users are currently working on platforms
- using tools and libraries that are under strict Non-Disclosure Agreements. In
- this situation it is impossible to submit changes to a traditional monolithic
- configuration header, instead some method by which the user can insert their
- own configuration code must be provided.
-
The solution
-
The approach taken by boost's configuration headers is to separate
- configuration into three orthogonal parts: the compiler, the standard library
- and the platform. Each compiler/standard library/platform gets its own
- mini-configuration header, so that changes to one compiler's configuration (for
- example) does not affect other compilers. In addition there are measures that
- can be taken both to omit the compiler/standard library/platform detection code
- (so that adding support to a new platform does not break dependencies), or to
- freeze the configuration completely; providing almost complete protection
- against dependency changes.
-
Acknowledgements
-
Beman Dawes provided the original config.hpp and part of this document. Vesa
- Karvonen provided a description of the principles (see rationale)
- and put together an early version of the current configuration setup. John
- Maddock put together the configuration current code, the test programs, the
- configuration script and the reference section of this document. Numerous boost
- members, past and present, have contributed fixes to boost's configuration.
+
+
diff --git a/doc/Jamfile.v2 b/doc/Jamfile.v2
new file mode 100644
index 00000000..ce5e46e9
--- /dev/null
+++ b/doc/Jamfile.v2
@@ -0,0 +1,62 @@
+# Boost.Config
+#
+# Copyright (c) 2001 Beman Dawes
+# Copyright (c) 2001 Vesa Karvonen
+# Copyright (c) 2001 John Maddock
+#
+# Distributed under the Boost Software License, Version 1.0.
+# (See accompanying file LICENSE_1_0.txt or copy at
+# http://www.boost.org/LICENSE_1_0.txt)
+
+
+# Quickbook
+# -----------------------------------------------------------------------------
+
+import quickbook ;
+
+path-constant boost-images : ../../../doc/src/images ;
+
+xml config
+ :
+ config.qbk
+ ;
+
+boostbook standalone
+ :
+ config
+ :
+ toc.max.depth=2
+ toc.section.depth=2
+ chunk.section.depth=1
+ boost.root=../../../..
+ boost.libraries=../../../../libs/libraries.htm
+ navig.graphics=1
+ html.stylesheet=../../../../doc/html/boostbook.css
+
+ # PDF Options:
+ # TOC Generation: this is needed for FOP-0.9 and later:
+ #fop1.extensions=1
+ # Or enable this if you're using XEP:
+ xep.extensions=1
+ # TOC generation: this is needed for FOP 0.2, but must not be set to zero for FOP-0.9!
+ fop.extensions=0
+ # No indent on body text:
+ body.start.indent=0pt
+ # Margin size:
+ page.margin.inner=0.5in
+ # Margin size:
+ page.margin.outer=0.5in
+ # Yes, we want graphics for admonishments:
+ admon.graphics=1
+ # Set this one for PDF generation *only*:
+ # default pnd graphics are awful in PDF form,
+ # better use SVG's instead:
+ pdf:admon.graphics.extension=".svg"
+ pdf:admon.graphics.path=$(boost-images)/
+ ;
+
+
+
+
+
+
diff --git a/doc/acknowledgements.qbk b/doc/acknowledgements.qbk
new file mode 100644
index 00000000..adbbb906
--- /dev/null
+++ b/doc/acknowledgements.qbk
@@ -0,0 +1,32 @@
+[/
+ Boost.Config
+
+ Copyright (c) 2001 Beman Dawes
+ Copyright (c) 2001 Vesa Karvonen
+ Copyright (c) 2001 John Maddock
+
+ Distributed under the Boost Software License, Version 1.0.
+ (See accompanying file LICENSE_1_0.txt or copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+]
+
+[section Acknowledgements]
+
+Beman Dawes provided the original `config.hpp` and part of this document.
+
+Vesa Karvonen provided a description of the principles (see
+[link config_rationale rationale]) and put together an early version of
+the current configuration setup.
+
+John Maddock put together the configuration current code, the test
+programs, the configuration script and the reference section of this
+document.
+
+Matias Capeletto converted the docs to quickbook format.
+
+Numerous boost members, past and present, have contributed fixes to boost's
+configuration.
+
+[endsect]
+
+
diff --git a/doc/config.qbk b/doc/config.qbk
new file mode 100644
index 00000000..7c83880d
--- /dev/null
+++ b/doc/config.qbk
@@ -0,0 +1,60 @@
+[article Boost.Config
+ [quickbook 1.4]
+ [authors [Beman Dawes, Vesa Karvonen, John Maddock] ]
+ [copyright 2001-2007 Beman Dawes, Vesa Karvonen, John Maddock]
+ [category broken compiler workarounds]
+ [id config]
+ [dirname config]
+ [purpose
+ Helps boost library developers adapt to compiler idiosyncrasies; not intended for library users.
+ ]
+ [source-mode c++]
+ [license
+Distributed under the Boost Software License, Version 1.0.
+(See accompanying file LICENSE_1_0.txt or copy at
+[@http://www.boost.org/LICENSE_1_0.txt])
+ ]
+]
+
+
+[/ Cited Boost resources ]
+
+[def __BOOST_REGRESSION_TEST_DRIVER__ [@../../../../more/regression.html boost regression test driver]]
+[def __BOOST_CONFIG_HEADER__ [@../../../../boost/config.hpp ]]
+[def __BOOST_CONFIG_USER_HEADER__ [@../../../../boost/config/user.hpp ]]
+[def __BOOST_CONFIG_SUFFIX_HEADER__ [@../../../../boost/config/user.hpp ]]
+[def __BOOST_CONFIG_DIR__ [']`/boost/config/`]
+
+
+[/ Other web resources ]
+
+[def __STL_PORT__ [@http://stlport.sourceforge.net STLport]]
+[def __BOOST_TRACKER__ [@http://sourceforge.net/tracker/?group_id=7586 Tracker]]
+[def __CORE_LANGUAGE_DR337__ [@http://www.open-std.org/jtc1/sc22/wg21/docs/cwg_defects.html#337 Core Language DR337]]
+[def __PRINCIPLES_AND_PATTERNS_ARTICLE__ [@http://www.objectmentor.com/resources/articles/Principles_and_Patterns.pdf following article]]
+
+
+[/ Icons ]
+
+[def __NOTE__ [$images/note.png]]
+[def __ALERT__ [$images/caution.png]]
+[def __DETAIL__ [$images/note.png]]
+[def __TIP__ [$images/tip.png]]
+[def __QUESTION_MARK__ [$images/question.png]]
+[def __SPACE__ [$images/space.png]]
+[def __GO_TO__ [$images/callouts/R.png]]
+
+
+[/ Document files ]
+
+
+[include configuring_boost.qbk]
+[include macro_reference.qbk]
+[include guidelines.qbk]
+[include rationale.qbk]
+[include acknowledgements.qbk]
+
+
+
+
+
diff --git a/doc/configuring_boost.qbk b/doc/configuring_boost.qbk
new file mode 100644
index 00000000..dc3d933e
--- /dev/null
+++ b/doc/configuring_boost.qbk
@@ -0,0 +1,434 @@
+[/
+ Boost.Config
+
+ Copyright (c) 2001 Beman Dawes
+ Copyright (c) 2001 Vesa Karvonen
+ Copyright (c) 2001 John Maddock
+
+ Distributed under the Boost Software License, Version 1.0.
+ (See accompanying file LICENSE_1_0.txt or copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+]
+
+
+[section Configuring Boost for Your Platform]
+
+
+[section Using the default boost configuration]
+
+Boost comes already configured for most common compilers and platforms; you
+should be able to use boost "as is". Since the compiler is configured
+separately from the standard library, the default configuration should work
+even if you replace the compiler's standard library with a third-party
+standard library (like __STL_PORT__).
+
+Using boost "as is" without trying to reconfigure is the recommended method
+for using boost. You can, however, run the configure script if you want to,
+and there are regression tests provided that allow you to test the current
+boost configuration with your particular compiler setup.
+
+Boost library users can request support for additional compilers or platforms
+by visiting our __BOOST_TRACKER__ and submitting a support request.
+
+[endsect]
+
+[section The header]
+
+Boost library implementations access configuration macros via
+
+ #include ``__BOOST_CONFIG_HEADER__``
+
+While Boost library users are not required to include that file directly, or
+use those configuration macros, such use is acceptable. The configuration
+macros are documented as to their purpose, usage, and limitations which makes
+them usable by both Boost library and user code.
+
+Boost [link config_info_macros informational] or [link config_helpers helper]
+macros are designed for use by Boost users as well as for our own internal use.
+Note however, that the [link config_features feature test] and
+[link config_defects defect test] macros were designed for internal use by
+Boost libraries, not user code, so they can change at any time (though no
+gratuitous changes are made to them). Boost library problems resulting from
+changes to the configuration macros are caught by the Boost regression tests,
+so the Boost libraries are updated to account for those changes. By contrast,
+Boost library user code can be adversely affected by changes to the macros
+without warning. The best way to keep abreast of changes to the macros used in
+user code is to monitor the discussions on the Boost developers list.
+
+[endsect]
+
+[#config_config_script]
+
+[section Using the configure script]
+
+[important
+This configure script only sets up the Boost headers for use with a particular
+compiler. It has no effect on Boost.Build, or how the libraries are built.
+]
+
+If you know that boost is incorrectly configured for your particular setup, and
+you are on a UNIX like platform, then you may want to try and improve things by
+running the boost configure script. From a shell command prompt you will need to
+cd into [']`/libs/config/` and type:
+
+[: `sh ./configure` ]
+
+you will see a list of the items being checked as the script works its way
+through the regression tests. Note that the configure script only really
+auto-detects your compiler if it's called g++, c++ or CC. If you are using
+some other compiler you will need to set one or more of the following
+environment variables:
+
+
+[table
+[[Variable][Description ]]
+[[CXX ][The name of the compiler, for example `c++`. ]]
+[[CXXFLAGS][The compiler flags to use, for example `-O2`. ]]
+[[LDFLAGS ][The linker flags to use, for example `-L/mypath`. ]]
+[[LIBS ][Any libraries to link in, for example `-lpthread`.]]
+]
+
+For example to run the configure script with HP aCC, you might use something
+like:
+
+ 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
+
+However you run the configure script, when it finishes you will find a
+new header -`user.hpp`- located in the [']`/libs/config/`
+directory. [*Note that configure does not install this header into your
+boost include path by default]. This header contains all the options
+generated by the configure script, plus a header-section that contains
+the user settable options from the default version of
+__BOOST_CONFIG_USER_HEADER__ (located under __BOOST_CONFIG_DIR__).
+There are two ways you can use this header:
+
+* [*Option 1:] copy the header into __BOOST_CONFIG_DIR__ so that it replaces
+the default user.hpp provided by boost. This option allows only one
+configure-generated setup; boost developers should avoid this option,
+as it incurs the danger of accidentally committing a configure-modified
+__BOOST_CONFIG_USER_HEADER__ to the cvs repository (something you will not
+be thanked for!).
+
+* [*Option 2:] give the header a more memorable name, and place it somewhere
+convenient; then, define the macro `BOOST_USER_CONFIG` to point to it. For
+example create a new sub-directory __BOOST_CONFIG_DIR__ `user/`, and copy
+the header there; for example as `multithread-gcc-config.hpp`. Then, when
+compiling add the command line option:
+`-DBOOST_USER_CONFIG=""`, and
+boost will use the new configuration header. This option allows you to
+generate more than one configuration header, and to keep them separate
+from the boost source - so that updates to the source do not interfere
+with your configuration.
+
+[endsect]
+
+[#config_user_settable]
+
+[section User settable options]
+
+There are some configuration-options that represent user choices, rather
+than compiler defects or platform specific options. These are listed in
+`` and at the start of a configure-generated `user.hpp`
+header. You can define these on the command line, or by editing
+``, they are listed in the following table:
+
+
+
+[table
+
+[[Macro ][Description ]]
+
+[[`BOOST_USER_CONFIG`][
+When defined, it should point to the name of the user configuration file
+to include prior to any boost configuration files. When not defined,
+defaults to [@../../../../boost/config/user.hpp ``].
+]]
+[[`BOOST_COMPILER_CONFIG`][
+When defined, it should point to the name of the compiler configuration
+file to use. Defining this cuts out the compiler selection logic, and
+eliminates the dependency on the header containing that logic. For
+example if you are using gcc, then you could define BOOST_COMPILER_CONFIG
+to [@../../../../boost/config/compiler/gcc.hpp ``].
+]]
+[[`BOOST_STDLIB_CONFIG`][
+When defined, it should point to the name of the standard library
+configuration file to use. Defining this cuts out the standard library
+selection logic, and eliminates the dependency on the header containing
+that logic. For example if you are using STLport, then you could define
+`BOOST_STDLIB_CONFIG` to
+[@../../../../boost/config/stdlib/stlport.hpp ``].
+]]
+[[`BOOST_PLATFORM_CONFIG`][
+When defined, it should point to the name of the platform configuration
+file to use. Defining this cuts out the platform selection logic, and
+eliminates the dependency on the header containing that logic. For example
+if you are compiling on linux, then you could define `BOOST_PLATFORM_CONFIG`
+to [@../../../../boost/config/platform/linux.hpp ``].
+]]
+[[`BOOST_NO_COMPILER_CONFIG`][
+When defined, no compiler configuration file is selected or included,
+define when the compiler is fully conformant with the standard, or where
+the user header (see `BOOST_USER_CONFIG`), has had any options necessary
+added to it, for example by an autoconf generated configure script.
+]]
+[[`BOOST_NO_STDLIB_CONFIG` ][
+When defined, no standard library configuration file is selected or included,
+define when the standard library is fully conformant with the standard, or
+where the user header (see `BOOST_USER_CONFIG`), has had any options necessary
+added to it, for example by an autoconf generated configure script.
+]]
+[[`BOOST_NO_PLATFORM_CONFIG` ][
+When defined, no platform configuration file is selected or included,
+define when the platform is fully conformant with the standard (and has
+no useful extra features), or where the user header (see
+`BOOST_USER_CONFIG`), has had any options necessary added to it, for example
+by an autoconf generated configure script.
+]]
+[[`BOOST_NO_CONFIG` ][
+Equivalent to defining all of `BOOST_NO_COMPILER_CONFIG`,
+`BOOST_NO_STDLIB_CONFIG` and `BOOST_NO_PLATFORM_CONFIG`.
+]]
+[[`BOOST_STRICT_CONFIG` ][
+The normal behavior for compiler versions that are newer than the last
+known version, is to assume that they have all the same defects as the
+last known version. By setting this define, then compiler versions that
+are newer than the last known version are assumed to be fully conforming
+with the standard. This is probably most useful for boost developers or
+testers, and for those who want to use boost to test beta compiler versions.
+]]
+[[`BOOST_ASSERT_CONFIG` ][
+When this flag is set, if the config finds anything unknown, then it will
+stop with a #error rather than continue. Boost regression testers should
+set this define, as should anyone who wants to quickly check whether boost
+is supported on their platform.
+]]
+[[`BOOST_DISABLE_THREADS` ][
+When defined, disables threading support, even if the compiler in its
+current translation mode supports multiple threads.
+]]
+[[`BOOST_DISABLE_WIN32` ][
+When defined, disables the use of Win32 specific API's, even when these
+are available. Also has the effect of setting `BOOST_DISABLE_THREADS` unless
+`BOOST_HAS_PTHREADS` is set. This option may be set automatically by the
+config system when it detects that the compiler is in "strict mode".
+]]
+[[`BOOST_DISABLE_ABI_HEADERS`][
+Stops boost headers from including any prefix/suffix headers that normally
+control things like struct packing and alignment.
+]]
+[[`BOOST_ABI_PREFIX`][
+A prefix header to include in place of whatever boost.config would normally
+select, any replacement should set up struct packing and alignment options
+as required.
+]]
+[[`BOOST_ABI_SUFFIX` ][
+A suffix header to include in place of whatever boost.config would normally
+select, any replacement should undo the effects of the prefix header.
+]]
+[[`BOOST_ALL_DYN_LINK`][
+Forces all libraries that have separate source, to be linked as dll's rather
+than static libraries on Microsoft Windows (this macro is used to turn on
+`__declspec(dllimport)` modifiers, so that the compiler knows which symbols
+to look for in a dll rather than in a static library).
+Note that there may be some libraries that can only be statically linked
+(Boost.Test for example) and others which may only be dynamically linked
+(Boost.Threads for example), in these cases this macro has no effect.
+]]
+[[`BOOST_`['WHATEVER]`_DYN_LINK`][
+Forces library "whatever" to be linked as a dll rather than a static library
+on Microsoft Windows: replace the ['WHATEVER] part of the macro name with the
+name of the library that you want to dynamically link to, for example use
+`BOOST_DATE_TIME_DYN_LINK` or `BOOST_REGEX_DYN_LINK` etc (this macro is used
+to turn on `__declspec(dllimport)` modifiers, so that the compiler knows
+which symbols to look for in a dll rather than in a static library).
+Note that there may be some libraries that can only be statically linked
+(Boost.Test for example) and others which may only be dynamically linked
+(Boost.Threads for example), in these cases this macro is unsupported.
+]]
+[[`BOOST_ALL_NO_LIB`][
+Tells the config system not to automatically select which libraries to link
+against.
+Normally if a compiler supports #pragma lib, then the correct library build
+variant will be automatically selected and linked against, simply by the act
+of including one of that library's headers. This macro turns that
+feature off.
+]]
+[[`BOOST_`['WHATEVER]`_NO_LIB`][
+Tells the config system not to automatically select which library to link
+against for library "whatever", replace ['WHATEVER] in the macro name with the
+name of the library; for example `BOOST_DATE_TIME_NO_LIB` or `BOOST_REGEX_NO_LIB`.
+Normally if a compiler supports `#pragma lib`, then the correct library build
+variant will be automatically selected and linked against, simply by the
+act of including one of that library's headers. This macro turns that
+feature off.
+]]
+[[`BOOST_LIB_DIAGNOSTIC`][
+Causes the auto-linking code to output diagnostic messages indicating the
+name of the library that is selected for linking.
+]]
+[[`BOOST_LIB_TOOLSET`][
+Overrides the name of the toolset part of the name of library being linked
+to; note if defined this must be defined to a quoted string literal, for
+example "abc".
+]]
+]
+
+[endsect]
+
+[section Advanced configuration usage]
+
+By setting various macros on the compiler command line or by editing
+__BOOST_CONFIG_USER_HEADER__, the boost configuration setup can be optimised
+in a variety of ways.
+
+Boost's configuration is structured so that the user-configuration is
+included first (defaulting to __BOOST_CONFIG_USER_HEADER__ if `BOOST_USER_CONFIG`
+is not defined). This sets up any user-defined policies, and gives the
+user-configuration a chance to influence what happens next.
+
+Next the compiler, standard library, and platform configuration files are
+included. These are included via macros (`BOOST_COMPILER_CONFIG` etc,
+[link config_user_settable see user settable macros]), and if the corresponding
+macro is undefined then a separate header that detects which compiler/standard
+library/platform is in use is included in order to set these. The config
+can be told to ignore these headers altogether if the corresponding
+`BOOST_NO_XXX` macro is set (for example `BOOST_NO_COMPILER_CONFIG` to
+disable including any compiler configuration file -
+[link config_user_settable see user settable macros]).
+
+Finally the boost configuration header, includes __BOOST_CONFIG_SUFFIX_HEADER__;
+this header contains any boiler plate configuration code - for example where one
+boost macro being set implies that another must be set also.
+
+The following usage examples represent just a few of the possibilities:
+
+[section Example 1, creating our own frozen configuration]
+
+Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0. Lets
+suppose also that we don't intend to update our compiler or standard library
+any time soon. In order to avoid breaking dependencies when we update boost,
+we may want to "freeze" our configuration headers, so that we only have to
+rebuild our project if the boost code itself has changed, and not because the
+boost config has been updated for more recent versions of Visual C++ or STLport.
+We'll start by realising that the configuration files in use are:
+[@../../../../boost/config/compiler/visualc.hpp ``]
+for the compiler,
+[@../../../../boost/config/stdlib/stlport.hpp ``]
+for the standard library, and
+[@../../../../boost/config/platform/win32.hpp ``]
+for the platform. Next we'll create our own private configuration directory:
+`boost/config/mysetup/`, and copy the configuration files into there. Finally,
+open up __BOOST_CONFIG_USER_HEADER__ and edit the following defines:
+
+ #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"
+
+Now when you use boost, its configuration header will go straight to our "frozen"
+versions, and ignore the default versions, you will now be insulated from any
+configuration changes when you update boost. This technique is also useful if
+you want to modify some of the boost configuration files; for example if you are
+working with a beta compiler release not yet supported by boost.
+
+[endsect]
+
+[section Example 2: skipping files that you don't need]
+
+Lets suppose that you're using boost with a compiler that is fully conformant with
+the standard; you're not interested in the fact that older versions of your compiler
+may have had bugs, because you know that your current version does not need any
+configuration macros setting. In a case like this, you can define
+`BOOST_NO_COMPILER_CONFIG` either on the command line, or in __BOOST_CONFIG_USER_HEADER__,
+and miss out the compiler configuration header altogether (actually you miss out
+two headers, one which works out what the compiler is, and one that configures
+boost for it). This has two consequences: the first is that less code has to be c
+ompiled, and the second that you have removed a dependency on two boost headers.
+
+[endsect]
+
+[section Example 3: using configure script to freeze the boost configuration]
+
+If you are working on a unix-like platform then you can use the configure script to
+generate a "frozen" configuration based on your current compiler setup -
+[link config_config_script see using the configure script for more details].
+
+[endsect]
+
+[endsect]
+
+[section Testing the boost configuration]
+
+The boost configuration library provides a full set of regression test programs
+under the __BOOST_CONFIG_DIR__ `test/` sub-directory:
+
+
+[table
+[[File][Description]]
+[[`config_info.cpp`][
+Prints out a detailed description of your compiler/standard library/platform
+setup, plus your current boost configuration. The information provided by this
+program useful in setting up the boost configuration files. If you report that
+boost is incorrectly configured for your compiler/library/platform then please
+include the output from this program when reporting the changes required.
+]]
+[[`config_test.cpp`][
+A monolithic test program that includes most of the individual test cases.
+This provides a quick check to see if boost is correctly configured for your
+compiler/library/platform.
+]]
+[[`limits_test.cpp`][
+Tests your standard library's `std::numeric_limits` implementation (or its boost
+provided replacement if `BOOST_NO_LIMITS` is defined). This test file fails with
+most versions of numeric_limits, mainly due to the way that some compilers
+treat NAN's and infinity.
+]]
+[[`no_*pass.cpp`][
+Individual compiler defect test files. Each of these should compile, if one
+does not then the corresponding `BOOST_NO_XXX` macro needs to be defined - see
+each test file for specific details.
+]]
+[[`no_*fail.cpp`][
+Individual compiler defect test files. Each of these should not compile, if
+one does then the corresponding `BOOST_NO_XXX` macro is defined when it need
+not be - see each test file for specific details.
+]]
+[[`has_*pass.cpp`][
+Individual feature test files. If one of these does not compile then the
+corresponding `BOOST_HAS_XXX` macro is defined when it should not be - see
+each test file for specific details.
+]]
+[[`has_*fail.cpp`][
+Individual feature test files. If one of these does compile then the
+corresponding `BOOST_HAS_XXX` macro can be safely defined - see each test
+file for specific details.
+]]
+]
+
+Although you can run the configuration regression tests as individual test
+files, there are rather a lot of them, so there are a couple of shortcuts to
+help you out:
+
+If you have built the __BOOST_REGRESSION_TEST_DRIVER__, then you can use this to
+produce a nice html formatted report of the results using the supplied test file.
+
+Alternatively you can run the configure script like this:
+
+[: `./configure --enable-test`]
+
+in which case the script will test the current configuration rather than
+creating a new one from scratch.
+
+If you are reporting the results of these tests for a new
+platform/library/compiler then please include a log of the full compiler output,
+the output from `config_info.cpp`, and the pass/fail test results.
+
+
+[endsect]
+
+[endsect]
+
diff --git a/doc/guidelines.qbk b/doc/guidelines.qbk
new file mode 100644
index 00000000..bd89209f
--- /dev/null
+++ b/doc/guidelines.qbk
@@ -0,0 +1,189 @@
+[/
+ Boost.Config
+
+ Copyright (c) 2001 Beman Dawes
+ Copyright (c) 2001 Vesa Karvonen
+ Copyright (c) 2001 John Maddock
+
+ Distributed under the Boost Software License, Version 1.0.
+ (See accompanying file LICENSE_1_0.txt or copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+]
+
+
+
+[section Guidelines for Boost Authors]
+
+The __BOOST_CONFIG_HEADER__ header is used to pass configuration information
+to other boost files, allowing them to cope with platform dependencies such
+as arithmetic byte ordering, compiler pragmas, or compiler shortcomings.
+Without such configuration information, many current compilers would not work
+with the Boost libraries.
+
+Centralizing configuration information in this header reduces the number of
+files that must be modified when porting libraries to new platforms, or when
+compilers are updated. Ideally, no other files would have to be modified when
+porting to a new platform.
+
+Configuration headers are controversial because some view them as condoning
+broken compilers and encouraging non-standard subsets. Adding settings for
+additional platforms and maintaining existing settings can also be a problem.
+In other words, configuration headers are a necessary evil rather than a
+desirable feature. The boost config.hpp policy is designed to minimize the
+problems and maximize the benefits of a configuration header.
+
+Note that:
+
+* Boost library implementers are not required to "`#include `",
+and are not required in any way to support compilers that do not comply
+with the C++ Standard (ISO/IEC 14882).
+* If a library implementer wishes to support some non-conforming compiler,
+or to support some platform specific feature, "`#include `"
+is the preferred way to obtain configuration information not available from
+the standard headers such as ``, etc.
+* If configuration information can be deduced from standard headers such as
+``, use those standard headers rather than ``.
+* Boost files that use macros defined in `` should have
+sensible, standard conforming, default behavior if the macro is not defined.
+This means that the starting point for porting `` to a new
+platform is simply to define nothing at all specific to that platform. In
+the rare case where there is no sensible default behavior, an #error message
+should describe the problem.
+* If a Boost library implementer wants something added to `config.hpp`, post
+a request on the Boost mailing list. There is no guarantee such a request
+will be honored; the intent is to limit the complexity of config.hpp.
+* The intent is to support only compilers which appear on their way to
+becoming C++ Standard compliant, and only recent releases of those compilers
+at that.
+* The intent is not to disable mainstream features now well-supported by the
+majority of compilers, such as namespaces, exceptions, RTTI, or templates.
+
+
+[section Adding New Defect Macros]
+
+When you need to add a new defect macro -either to fix a problem with an
+existing library, or when adding a new library- distil the issue down to
+a simple test case; often, at this point other (possibly better) workarounds
+may become apparent. Secondly always post the test case code to the boost
+mailing list and invite comments; remember that C++ is complex and that
+sometimes what may appear a defect, may in fact turn out to be a problem
+with the authors understanding of the standard.
+
+When you name the macro, follow the `BOOST_NO_`['SOMETHING] naming
+convention, so that it's obvious that this is a macro reporting a defect.
+
+Finally, add the test program to the regression tests. You will need to
+place the test case in a `.ipp` file with the following comments near the top:
+
+ // MACRO: BOOST_NO_FOO
+ // TITLE: foo
+ // DESCRIPTION: If the compiler fails to support foo
+
+These comments are processed by the autoconf script, so make sure the format
+follows the one given. The file should be named "`boost_no_foo.ipp`", where foo
+is the defect description -try and keep the file name under the Mac 30 character
+filename limit though. You will also need to provide a function prototype
+"`int test()`" that is declared in a namespace with the same name as the macro,
+but in all lower case, and which returns zero on success:
+
+ namespace boost_no_foo {
+
+ int test()
+ {
+ // test code goes here:
+ //
+ return 0;
+ }
+
+ }
+
+Once the test code is in place in libs/config/test, updating the configuration
+test system proceeds as:
+
+* cd into `libs/config/tools` and run `bjam --v2` : this generates the `.cpp`
+file test cases from the `.ipp` file, updates the Jamfile, `config_test.cpp` and
+`config_info.cpp`.
+* cd into `libs/config/test` and run `bjam --v2 `['MACRONAME]` compiler-list` : where
+['MACRONAME] is the name of the new macro, and `compiler-list` is the list of
+compilers to test with. You should see the tests pass with those compilers
+that don't have the defect, and fail with those that do.
+* cd into `libs/config/test` and `run bjam --v2 config_info config_test compiler-list` :
+`config_info` should build and run cleanly for all the compilers in `compiler-list`
+while `config_test` should fail for those that have the defect, and pass for those
+that do not.
+
+Then you should:
+
+* Define the defect macro in those config headers that require it.
+* Document the macro in this documentation (please do not forget this step!!)
+* Commit everything.
+* Keep an eye on the regression tests for new failures in Boost.Config caused by
+the addition.
+* Start using the macro.
+
+[endsect]
+
+[section Adding New Feature Test Macros]
+
+When you need to add a macro that describes a feature that the standard does
+not require, follow the convention for adding a new defect macro (above), but
+call the macro `BOOST_HAS_FOO`, and name the test file "`boost_has_foo.ipp`".
+Try not to add feature test macros unnecessarily, if there is a platform
+specific macro that can already be used (for example `_WIN32`, `__BEOS__`, or
+`__linux`) to identify the feature then use that. Try to keep the macro to a
+feature group, or header name, rather than one specific API (for example
+`BOOST_HAS_NL_TYPES_H` rather than `BOOST_HAS_CATOPEN`). If the macro
+describes a POSIX feature group, then add boilerplate code to
+__BOOST_CONFIG_SUFFIX_HEADER__ to auto-detect the feature where possible
+(if you are wondering why we can't use POSIX feature test macro directly,
+remember that many of these features can be added by third party libraries,
+and are not therefore identified inside ``).
+
+[endsect]
+
+[section Modifying the Boost Configuration Headers]
+
+The aim of boost's configuration setup is that the configuration headers should
+be relatively stable - a boost user should not have to recompile their code
+just because the configuration for some compiler that they're not interested
+in has changed. Separating the configuration into separate compiler/standard
+library/platform sections provides for part of this stability, but boost
+authors require some amount of restraint as well, in particular:
+
+__BOOST_CONFIG_HEADER__ should never change, don't alter this file.
+
+__BOOST_CONFIG_USER_HEADER__ is included by default, don't add extra code to
+this file unless you have to. If you do, please remember to update
+[@../../tools/configure.in libs/config/tools/configure.in] as well.
+
+__BOOST_CONFIG_SUFFIX_HEADER__ is always included so be careful about
+modifying this file as it breaks dependencies for everyone. This file should
+include only "boilerplate" configuration code, and generally should change
+only when new macros are added.
+
+[@../../../../boost/config/select_compiler_config.hpp ],
+[@../../../../boost/config/select_platform_config.hpp ] and
+[@../../../../boost/config/select_stdlib_config.hpp ]
+are included by default and should change only if support for a new
+compiler/standard library/platform is added.
+
+The compiler/platform/standard library selection code is set up so that unknown
+platforms are ignored and assumed to be fully standards compliant -this gives
+unknown platforms a "sporting chance" of working "as is" even without running
+the configure script.
+
+When adding or modifying the individual mini-configs, assume that future, as
+yet unreleased versions of compilers, have all the defects of the current
+version. Although this is perhaps unnecessarily pessimistic, it cuts down on
+the maintenance of these files, and experience suggests that pessimism is
+better placed than optimism here!
+
+[endsect]
+
+[endsect]
+
+
+
+
+
+
diff --git a/doc/html/HTML.manifest b/doc/html/HTML.manifest
new file mode 100644
index 00000000..632c78f1
--- /dev/null
+++ b/doc/html/HTML.manifest
@@ -0,0 +1,5 @@
+index.html
+boost_config/boost_macro_reference.html
+boost_config/guidelines_for_boost_authors.html
+boost_config/rationale.html
+boost_config/acknowledgements.html
diff --git a/doc/html/boost_config/acknowledgements.html b/doc/html/boost_config/acknowledgements.html
new file mode 100644
index 00000000..11e53886
--- /dev/null
+++ b/doc/html/boost_config/acknowledgements.html
@@ -0,0 +1,60 @@
+
+
+
+Acknowledgements
+
+
+
+
+
+
+
+
+ Beman Dawes provided the original config.hpp and
+ part of this document.
+
+
+ Vesa Karvonen provided a description of the principles (see rationale)
+ and put together an early version of the current configuration setup.
+
+
+ John Maddock put together the configuration current code, the test programs,
+ the configuration script and the reference section of this document.
+
+
+ Matias Capeletto converted the docs to quickbook format.
+
+
+ Numerous boost members, past and present, have contributed fixes to boost's
+ configuration.
+
+ The following macros all describe features that are required by the C++ standard,
+ if one of the following macros is defined, then it represents a defect in
+ the compiler's conformance with the standard.
+
+
+
+
+
+
+
+
+
+
+ Macro
+
+
+
+
+ Section
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ BOOST_BCB_PARTIAL_SPECIALIZATION_BUG
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler exibits certain partial specialisation bug - probably
+ Borland C++ Builder specific.
+
+ Argument dependent lookup fails if there is a using declaration for
+ the symbol being looked up in the current scope. For example, using
+ boost::get_pointer; prevents ADL from
+ finding overloads of get_pointer
+ in namespaces nested inside boost (but not elsewhere). Probably Borland
+ specific.
+
+
+
+
+
+
+ BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP
+
+
+
+
+ Compiler
+
+
+
+
+ Compiler does not implement argument-dependent lookup (also named
+ Koenig lookup); see std::3.4.2 [basic.koenig.lookup]
+
+
+
+
+
+
+ BOOST_NO_AUTO_PTR
+
+
+
+
+ Standard library
+
+
+
+
+ If the compiler / library supplies non-standard or broken std::auto_ptr.
+
+
+
+
+
+
+ BOOST_NO_CTYPE_FUNCTIONS
+
+
+
+
+ Platform
+
+
+
+
+ The Platform does not provide functions for the character-classifying
+ operations <ctype.h> and <cctype>,
+ only macros.
+
+
+
+
+
+
+ BOOST_NO_CV_SPECIALIZATIONS
+
+
+
+
+ Compiler
+
+
+
+
+ If template specialisations for cv-qualified types conflict with
+ a specialisation for a cv-unqualififed type.
+
+
+
+
+
+
+ BOOST_NO_CV_VOID_SPECIALIZATIONS
+
+
+
+
+ Compiler
+
+
+
+
+ If template specialisations for cv-void types conflict with a specialisation
+ for void.
+
+
+
+
+
+
+ BOOST_NO_CWCHAR
+
+
+
+
+ Platform
+
+
+
+
+ The Platform does not provide <wchar.h>
+ and <cwchar>.
+
+
+
+
+
+
+ BOOST_NO_CWCTYPE
+
+
+
+
+ Platform
+
+
+
+
+ The Platform does not provide <wctype.h>
+ and <cwctype>.
+
+
+
+
+
+
+ BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler fails to compile a nested class that has a dependent
+ base class:
+
+ The standard library does not put some or all of the contents of
+ <exception> in namespace std.
+
+
+
+
+
+
+ BOOST_NO_EXCEPTIONS
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not support exception handling (this setting is
+ typically required by many C++ compilers for embedded platforms).
+ Note that there is no requirement for boost libraries to honor this
+ configuration setting - indeed doing so may be impossible in some
+ cases. Those libraries that do honor this will typically abort if
+ a critical error occurs - you have been warned!
+
+
+
+
+
+
+ BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS
+
+
+
+
+ Compiler
+
+
+
+
+ Can only use deduced template arguments when calling function template
+ instantiations.
+
+
+
+
+
+
+ BOOST_NO_FUNCTION_TEMPLATE_ORDERING
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not perform function template ordering or its function
+ template ordering is incorrect.
+
+ The C++ implementation does not provide wchar_t,
+ or it is really a synonym for another integral type. Use this symbol
+ to decide whether it is appropriate to explicitly specialize a template
+ on wchar_t if there
+ is already a specialization for other integer types.
+
+
+
+
+
+
+ BOOST_NO_IOSFWD
+
+
+
+
+ std lib
+
+
+
+
+ The standard library lacks <iosfwd>.
+
+
+
+
+
+
+ BOOST_NO_IOSTREAM
+
+
+
+
+ std lib
+
+
+
+
+ The standard library lacks <iostream>,
+ <istream> or <ostream>.
+
+
+
+
+
+
+ BOOST_NO_IS_ABSTRACT
+
+
+
+
+ Compiler
+
+
+
+
+ The C++ compiler does not support SFINAE with abstract types, this
+ is covered by Core
+ Language DR337, but is not part of the current standard.
+ Fortunately most compilers that support SFINAE also support this
+ DR.
+
+
+
+
+
+
+ BOOST_NO_LIMITS
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ implementation does not provide the <limits>
+ header. Never check for this symbol in library code; always include
+ <boost/limits.hpp>, which guarantees to provide
+ std::numeric_limits.
+
+
+
+
+
+
+ BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
+
+
+
+
+ Standard library
+
+
+
+
+ Constants such as numeric_limits<T>::is_signed
+ are not available for use at compile-time.
+
+
+
+
+
+
+ BOOST_NO_LONG_LONG_NUMERIC_LIMITS
+
+
+
+
+ Standard library
+
+
+
+
+ There is no specialization for numeric_limits<long
+ long>
+ and numeric_limits<unsigned
+ longlong>. <boost/limits.hpp>
+ will then add these specializations as a standard library "fix"
+ only if the compiler supports the long
+ long datatype.
+
+
+
+
+
+
+ BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not support the specialization of individual member
+ functions of template classes.
+
+
+
+
+
+
+ BOOST_NO_MEMBER_TEMPLATE_KEYWORD
+
+
+
+
+ Compiler
+
+
+
+
+ If the compiler supports member templates, but not the template keyword
+ when accessing member template classes.
+
+
+
+
+
+
+ BOOST_NO_MEMBER_TEMPLATE_FRIENDS
+
+
+
+
+ Compiler
+
+
+
+
+ Member template friend syntax (template<class
+ P>
+ friendclass
+ frd;)
+ described in the C++ Standard, 14.5.3, not supported.
+
+
+
+
+
+
+ BOOST_NO_MEMBER_TEMPLATES
+
+
+
+
+ Compiler
+
+
+
+
+ Member template functions not fully supported.
+
+
+
+
+
+
+ BOOST_NO_MS_INT64_NUMERIC_LIMITS
+
+
+
+
+ Standard library
+
+
+
+
+ There is no specialization for numeric_limits<__int64> and numeric_limits<unsigned
+ __int64>.
+ <boost/limits.hpp> will then add these specializations
+ as a standard library "fix", only if the compiler supports
+ the __int64 datatype.
+
+
+
+
+
+
+ BOOST_NO_OPERATORS_IN_NAMESPACE
+
+
+
+
+ Compiler
+
+
+
+
+ Compiler requires inherited operator friend functions to be defined
+ at namespace scope, then using'ed to boost. Probably GCC specific.
+ See <boost/operators.hpp>
+ for example.
+
+
+
+
+
+
+ BOOST_NO_POINTER_TO_MEMBER_CONST
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not correctly handle pointers to const member functions,
+ preventing use of these in overloaded function templates. See <boost/functional.hpp>
+ for example.
+
+ Pointers to members don't work when used as template parameters.
+
+
+
+
+
+
+ BOOST_NO_PRIVATE_IN_AGGREGATE
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler misreads 8.5.1, treating classes as non-aggregate if
+ they contain private or protected member functions.
+
+
+
+
+
+
+ BOOST_NO_SFINAE
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not support the "Substitution Failure Is Not
+ An Error" meta-programming idiom.
+
+
+
+
+
+
+ BOOST_NO_STD_ALLOCATOR
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ standard library does not provide a standards conforming
+ std::allocator.
+
+
+
+
+
+
+ BOOST_NO_STD_DISTANCE
+
+
+
+
+ Standard library
+
+
+
+
+ The platform does not have a conforming version of std::distance.
+
+
+
+
+
+
+ BOOST_NO_STD_ITERATOR
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ implementation fails to provide the std::iterator
+ class.
+
+
+
+
+
+
+ BOOST_NO_STD_ITERATOR_TRAITS
+
+
+
+
+ Standard library
+
+
+
+
+ The compiler does not provide a standard compliant implementation
+ of std::iterator_traits. Note that the
+ compiler may still have a non-standard implementation.
+
+
+
+
+
+
+ BOOST_NO_STD_LOCALE
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks std::locale.
+
+
+
+
+
+
+ BOOST_NO_STD_MESSAGES
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks a conforming std::messages
+ facet.
+
+
+
+
+
+
+ BOOST_NO_STD_MIN_MAX
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ standard library does not provide the min() and max() template functions that should
+ be in <algorithm>.
+
+
+
+
+
+
+ BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN
+
+
+
+
+ Standard library
+
+
+
+
+ Defined if the standard library's output iterators are not assignable.
+
+
+
+
+
+
+ BOOST_NO_STD_TYPEINFO
+
+
+
+
+ Standard library
+
+
+
+
+ The <typeinfo> header declares type_info
+ in the global namespace instead of namespace std.
+
+
+
+
+
+
+ BOOST_NO_STD_USE_FACET
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks a conforming std::use_facet.
+
+
+
+
+
+
+ BOOST_NO_STD_WSTREAMBUF
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library's implementation of std::basic_streambuf<wchar_t> is either missing, incomplete,
+ or buggy.
+
+
+
+
+
+
+ BOOST_NO_STD_WSTRING
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks std::wstring.
+
+
+
+
+
+
+ BOOST_NO_STDC_NAMESPACE
+
+
+
+
+ Compiler, Platform
+
+
+
+
+ The contents of C++ standard headers for C library functions (the
+ <c...> headers) have not been placed
+ in namespace std. This test is difficult - some libraries "fake"
+ the std C functions by adding using declarations to import them into
+ namespace std, unfortunately they don't necessarily catch all of
+ them...
+
+
+
+
+
+
+ BOOST_NO_STRINGSTREAM
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ implementation does not provide the <sstream>
+ header.
+
+
+
+
+
+
+ BOOST_NO_SWPRINTF
+
+
+
+
+ Platform
+
+
+
+
+ The platform does not have a conforming version of swprintf.
+
+
+
+
+
+
+ BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION
+
+
+
+
+ Compiler
+
+
+
+
+ Class template partial specialization (14.5.4 [temp.class.spec])
+ not supported.
+
+
+
+
+
+
+ BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library does not provide templated iterator constructors
+ for its containers.
+
+
+
+
+
+
+ BOOST_NO_TEMPLATE_TEMPLATES
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not support template template parameters.
+
+
+
+
+
+
+ BOOST_NO_TYPEID
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not support the typeid operator at all.
+
+
+
+
+
+
+ BOOST_NO_UNREACHABLE_RETURN_DETECTION
+
+
+
+
+ Compiler
+
+
+
+
+ If a return is unreachable, then no return statement should be required,
+ however some compilers insist on it, while other issue a bunch of
+ warnings if it is in fact present.
+
+ The compiler will not accept a using declaration that brings a function
+ from a typename used as a base class into a derived class if functions
+ of the same name are present in the derived class.
+
+
+
+
+
+
+ BOOST_NO_USING_TEMPLATE
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler will not accept a using declaration that imports a template
+ class or function from another namespace. Originally a Borland specific
+ problem with imports to/from the global namespace, extended to MSVC6
+ which has a specific issue with importing template classes (but not
+ functions).
+
+
+
+
+
+
+ BOOST_NO_VOID_RETURNS
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler does not allow a void function to return the result
+ of calling another void function.
+
+ The following macros describe features that are not required by the C++ standard.
+ The macro is only defined if the feature is present.
+
+
+
+
+
+
+
+
+
+
+ Macro
+
+
+
+
+ Section
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ BOOST_HAS_BETHREADS
+
+
+
+
+ Platform
+
+
+
+
+ The platform supports BeOS style threads.
+
+
+
+
+
+
+ BOOST_HAS_CLOCK_GETTIME
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API clock_gettime.
+
+
+
+
+
+
+ BOOST_HAS_DECLSPEC
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler uses __declspec(dllexport) and __declspec(dllimport) to export/import symbols from dll's.
+
+
+
+
+
+
+ BOOST_HAS_DIRENT_H
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX header <dirent.h>.
+
+
+
+
+
+
+ BOOST_HAS_EXPM1
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the functions expm1,
+ expm1f and expm1l in <math.h>
+
+
+
+
+
+
+ BOOST_HAS_FTIME
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the Win32 API GetSystemTimeAsFileTime.
+
+
+
+
+
+
+ BOOST_HAS_GETTIMEOFDAY
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API gettimeofday.
+
+
+
+
+
+
+ BOOST_HAS_HASH
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ implementation provides the (SGI) hash_set and hash_map classes.
+ When defined, BOOST_HASH_SET_HEADER
+ and BOOST_HASH_LIST_HEADER
+ will contain the names of the header needed to access hash_set and
+ hash_map; BOOST_STD_EXTENSION_NAMESPACE
+ will provide the namespace in which the two class templates reside.
+
+
+
+
+
+
+ BOOST_HAS_LOG1P
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the functions log1p,
+ log1pf and log1pl in <math.h>.
+
+
+
+
+
+
+ BOOST_HAS_MACRO_USE_FACET
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks a conforming std::use_facet,
+ but has a macro _USE(loc,Type) that does the job. This is primarily
+ for the Dinkumware std lib.
+
+
+
+
+
+
+ BOOST_HAS_MS_INT64
+
+
+
+
+ Compiler
+
+
+
+
+ The compiler supports the __int64
+ data type.
+
+
+
+
+
+
+ BOOST_HAS_NANOSLEEP
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API nanosleep.
+
+
+
+
+
+
+ BOOST_HAS_NL_TYPES_H
+
+
+
+
+ Platform
+
+
+
+
+ The platform has an <nl_types.h>.
+
+
+
+
+
+
+ BOOST_HAS_NRVO
+
+
+
+
+ Compiler
+
+
+
+
+ Indicated that the compiler supports the named return value optimization
+ (NRVO). Used to select the most efficient implementation for some
+ function. See <boost/operators.hpp> for example.
+
+
+
+
+
+
+ BOOST_HAS_PARTIAL_STD_ALLOCATOR
+
+
+
+
+ Standard Library
+
+
+
+
+ The standard library has a partially conforming std::allocator
+ class, but without any of the member templates.
+
+
+
+
+
+
+ BOOST_HAS_PTHREAD_DELAY_NP
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API pthread_delay_np.
+
+
+
+
+
+
+ BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API pthread_mutexattr_settype.
+
+
+
+
+
+
+ BOOST_HAS_PTHREAD_YIELD
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API pthread_yield.
+
+
+
+
+
+
+ BOOST_HAS_PTHREADS
+
+
+
+
+ Platform
+
+
+
+
+ The platform support POSIX style threads.
+
+
+
+
+
+
+ BOOST_HAS_SCHED_YIELD
+
+
+
+
+ Platform
+
+
+
+
+ The platform has the POSIX API sched_yield.
+
+
+
+
+
+
+ BOOST_HAS_SGI_TYPE_TRAITS
+
+
+
+
+ Compiler, Standard library
+
+
+
+
+ The compiler has native support for SGI style type traits.
+
+
+
+
+
+
+ BOOST_HAS_STDINT_H
+
+
+
+
+ Platform
+
+
+
+
+ The platform has a <stdint.h>
+
+
+
+
+
+
+ BOOST_HAS_SLIST
+
+
+
+
+ Standard library
+
+
+
+
+ The C++ implementation provides the (SGI) slist class. When defined,
+ BOOST_SLIST_HEADER
+ will contain the name of the header needed to access slist and BOOST_STD_EXTENSION_NAMESPACE
+ will provide the namespace in which slist
+ resides.
+
+
+
+
+
+
+ BOOST_HAS_STLP_USE_FACET
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks a conforming std::use_facet,
+ but has a workaround class-version that does the job. This is primarily
+ for the STLport std lib.
+
+
+
+
+
+
+ BOOST_HAS_TR1_ARRAY
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <array>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_COMPLEX_OVERLOADS
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a version of <complex>
+ that supports passing scalars to the complex number algorithms.
+
+
+
+
+
+
+ BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a version of <complex>
+ that includes the new inverse trig functions from TR1.
+
+
+
+
+
+
+ BOOST_HAS_TR1_REFERENCE_WRAPPER
+
+
+
+
+ Standard library
+
+
+
+
+ The library has TR1 conforming reference wrappers in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_RESULT_OF
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming result_of template in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_MEM_FN
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming mem_fn function template in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_BIND
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming bind function template in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_FUNCTION
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming function class template in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_HASH
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming hash function template in <functional>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_SHARED_PTR
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming shared_ptr
+ class template in <memory>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_RANDOM
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <random>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_REGEX
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <regex>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_TUPLE
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <tuple>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_TYPE_TRAITS
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <type_traits>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_UTILITY
+
+
+
+
+ Standard library
+
+
+
+
+ The library has the TR1 additions to <utility>
+ (tuple interface to std::pair).
+
+
+
+
+
+
+ BOOST_HAS_TR1_UNORDERED_MAP
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <unordered_map>.
+
+
+
+
+
+
+ BOOST_HAS_TR1_UNORDERED_SET
+
+
+
+
+ Standard library
+
+
+
+
+ The library has a TR1 conforming version of <unordered_set>.
+
+
+
+
+
+
+ BOOST_HAS_TR1
+
+
+
+
+ Standard library
+
+
+
+
+ Implies all the other BOOST_HAS_TR1_* macros should be set.
+
+
+
+
+
+
+ BOOST_HAS_THREADS
+
+
+
+
+ Platform, Compiler
+
+
+
+
+ Defined if the compiler, in its current translation mode, supports
+ multiple threads of execution.
+
+
+
+
+
+
+ BOOST_HAS_TWO_ARG_USE_FACET
+
+
+
+
+ Standard library
+
+
+
+
+ The standard library lacks a conforming std::use_facet, but has a
+ two argument version that does the job. This is primarily for the
+ Rogue Wave std lib.
+
+
+
+
+
+
+ BOOST_HAS_UNISTD_H
+
+
+
+
+ Platform
+
+
+
+
+ The Platform provides <unistd.h>.
+
+
+
+
+
+
+ BOOST_HAS_WINTHREADS
+
+
+
+
+ Platform
+
+
+
+
+ The platform supports MS Windows style threads.
+
+
+
+
+
+
+ BOOST_MSVC_STD_ITERATOR
+
+
+
+
+ Standard library
+
+
+
+
+ Microsoft's broken version of std::iterator
+ is being used. This implies that std::iterator
+ takes no more than two template parameters.
+
+
+
+
+
+
+ BOOST_MSVC6_MEMBER_TEMPLATES
+
+
+
+
+ Compiler
+
+
+
+
+ Microsoft Visual C++ 6.0 has enough member template idiosyncrasies
+ (being polite) that BOOST_NO_MEMBER_TEMPLATES
+ is defined for this compiler. BOOST_MSVC6_MEMBER_TEMPLATES
+ is defined to allow compiler specific workarounds. This macro gets
+ defined automatically if BOOST_NO_MEMBER_TEMPLATES
+ is not defined - in other words this is treated as a strict subset
+ of the features required by the standard.
+
+
+
+
+
+
+ BOOST_HAS_STDINT_H
+
+
+
+
+ Platform
+
+
+
+
+ There are no 1998 C++ Standard headers <stdint.h>
+ or <cstdint>, although the 1999 C Standard
+ does include <stdint.h>. If <stdint.h>
+ is present, <boost/stdint.h> can make good use of it, so a
+ flag is supplied (signalling presence; thus the default is not present,
+ conforming to the current C++ standard).
+
+ The following macros are either simple helpers, or macros that provide workarounds
+ for compiler/standard library defects.
+
+
+
+
+
+
+
+
+
+ Macro
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ BOOST_DEDUCED_TYPENAME
+
+
+
+
+ Some compilers don't support the use of typename for dependent types
+ in deduced contexts. This macro expands to nothing on those compilers,
+ and typename elsewhere. For example, replace: template
+ <class
+ T>
+ voidf(T,typename
+ T::type);
+ with: template<classT>void
+ f(T,BOOST_DEDUCED_TYPENAMET::type);
+
+
+
+
+
+
+ BOOST_HASH_MAP_HEADER
+
+
+
+
+ The header to include to get the SGI hash_map
+ class. This macro is only available if BOOST_HAS_HASH
+ is defined.
+
+
+
+
+
+
+ BOOST_HASH_SET_HEADER
+
+
+
+
+ The header to include to get the SGI hash_set
+ class. This macro is only available if BOOST_HAS_HASH
+ is defined.
+
+
+
+
+
+
+ BOOST_SLIST_HEADER
+
+
+
+
+ The header to include to get the SGI slist
+ class. This macro is only available if BOOST_HAS_SLIST
+ is defined.
+
+
+
+
+
+
+ BOOST_STD_EXTENSION_NAMESPACE
+
+
+
+
+ The namespace used for std library extensions (hashtable classes
+ etc).
+
+
+
+
+
+
+ BOOST_STATIC_CONSTANT(Type,assignment)
+
+
+
+
+ On compilers which don't allow in-class initialization of static
+ integral constant members, we must use enums as a workaround if we
+ want the constants to be available at compile-time. This macro gives
+ us a convenient way to declare such constants. For example instead
+ of:
+
+ Some compilers silently "fold" different function template
+ instantiations if some of the template parameters don't appear in
+ the function parameter list. For instance:
+
+ incorrectly outputs 2 2 double double on VC++
+ 6. These macros, to be used in the function parameter list, fix the
+ problem without effects on the calling syntax. For instance, in the
+ case above write:
+
+ Beware that they can declare (for affected compilers) a dummy defaulted
+ parameter, so they
+
+
+ a) should be always invoked at the end of the parameter list
+
+
+ b) can't be used if your function
+ template is multiply declared.
+
+
+ Furthermore, in order to add any needed comma separator, an APPEND_*
+ version must be used when the macro invocation appears after a normal
+ parameter declaration or after the invocation of another macro of
+ this same group.
+
+
+
+
+
+
+ BOOST_USE_FACET(Type,
+ loc)
+
+
+
+
+ When the standard library does not have a comforming std::use_facet there are various workarounds
+ available, but they differ from library to library. This macro provides
+ a consistent way to access a locale's facets. For example, replace:
+ std::use_facet<Type>(loc);
+ with: BOOST_USE_FACET(Type,loc); Note do not add a std::
+ prefix to the front of BOOST_USE_FACET.
+
+
+
+
+
+
+ BOOST_HAS_FACET(Type,
+ loc)
+
+
+
+
+ When the standard library does not have a comforming std::has_facet there are various workarounds
+ available, but they differ from library to library. This macro provides
+ a consistent way to check a locale's facets. For example, replace:
+ std::has_facet<Type>(loc);
+ with: BOOST_HAS_FACET(Type,loc); Note do not add a std::
+ prefix to the front of BOOST_HAS_FACET.
+
+
+
+
+
+
+ BOOST_NESTED_TEMPLATE
+
+
+
+
+ Member templates are supported by some compilers even though they
+ can't use the A::templatemember<U> syntax, as a workaround replace:
+ typedeftypename
+ A::templaterebind<U>binder; with: typedef
+ typenameA::BOOST_NESTED_TEMPLATE
+ rebind<U>
+ binder;
+
+
+
+
+
+
+ BOOST_STRINGIZE(X)
+
+
+
+
+ Converts the parameter X
+ to a string after macro replacement on X
+ has been performed.
+
+
+
+
+
+
+ BOOST_JOIN(X,Y)
+
+
+
+
+ This piece of macro magic joins the two arguments together, even
+ when one of the arguments is itself a macro (see 16.3.1 in C++ standard).
+ This is normally used to create a mangled name in combination with
+ a predefined macro such a __LINE__.
+
+ The following macros describe boost features; these are, generally speaking
+ the only boost macros that should be tested in user code.
+
+
+
+
+
+
+
+
+
+
+ Macro
+
+
+
+
+ Header
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ BOOST_VERSION
+
+
+
+
+ <boost/version.hpp>
+
+
+
+
+ Describes the boost version number in XXYYZZ format such that: (BOOST_VERSION
+ %100) is the sub-minor version, ((BOOST_VERSION
+ /100)%1000)
+ is the minor version, and (BOOST_VERSION/
+ 100000)
+ is the major version.
+
+
+
+
+
+
+ BOOST_NO_INT64_T
+
+
+
+
+ <boost/cstdint.hpp><boost/stdint.h>
+
+
+
+
+ Defined if there are no 64-bit integral types: int64_t,
+ uint64_t etc.
+
+
+
+
+
+
+ BOOST_NO_INTEGRAL_INT64_T
+
+
+
+
+ <boost/cstdint.hpp><boost/stdint.h>
+
+
+
+
+ Defined if int64_t
+ as defined by <boost/cstdint.hpp> is not usable in integral constant
+ expressions.
+
+
+
+
+
+
+ BOOST_MSVC
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined if the compiler is really Microsoft Visual C++, as opposed
+ to one of the many other compilers that also define _MSC_VER.
+
+
+
+
+
+
+ BOOST_INTEL
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined if the compiler is an Intel compiler, takes the same value
+ as the compiler version macro.
+
+
+
+
+
+
+ BOOST_WINDOWS
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined if the Windows platfrom API is available.
+
+
+
+
+
+
+ BOOST_DINKUMWARE_STDLIB
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined if the dinkumware standard library is in use, takes the same
+ value as the Dinkumware library version macro _CPPLIB_VER
+ if defined, otherwise 1.
+
+
+
+
+
+
+ BOOST_NO_WREGEX
+
+
+
+
+ <boost/regex.hpp>
+
+
+
+
+ Defined if the regex library does not support wide character regular
+ expressions.
+
+
+
+
+
+
+ BOOST_COMPILER
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined as a string describing the name and version number of the
+ compiler in use. Mainly for debugging the configuration.
+
+
+
+
+
+
+ BOOST_STDLIB
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined as a string describing the name and version number of the
+ standard library in use. Mainly for debugging the configuration.
+
+
+
+
+
+
+ BOOST_PLATFORM
+
+
+
+
+ <boost/config.hpp>
+
+
+
+
+ Defined as a string describing the name of the platform. Mainly for
+ debugging the configuration.
+
+ The following macros and helper headers are of use to authors whose libraries
+ include separate source code, and are intended to address two issues: fixing
+ the ABI of the compiled library, and selecting which compiled library to
+ link against based upon the compilers settings.
+
+ When linking against a pre-compiled library it vital that the ABI used
+ by the compiler when building the library matches exactly
+ the ABI used by the code using the library. In this case ABI means things
+ like the struct packing arrangement used, the name mangling scheme used,
+ or the size of some types (enum types for example). This is separate from
+ things like threading support, or runtime library variations, which have
+ to be dealt with by build variants. To put this in perspective there is
+ one compiler (Borland's) that has so many compiler options that make subtle
+ changes to the ABI, that at least in theory there 3200 combinations, and
+ that's without considering runtime library variations. Fortunately these
+ variations can be managed by #pragma's
+ that tell the compiler what ABI to use for the types declared in your library.
+ In order to avoid sprinkling #pragma's
+ all over the boost headers, there are some prefix and suffix headers that
+ do the job. Typical usage is:
+
+
+ my_library.hpp
+
+
+#ifndefMY_INCLUDE_GUARD
+#defineMY_INCLUDE_GUARD
+
+// all includes go here:
+#include <boost/config.hpp>
+#include<whatever>
+
+#include <boost/config/abi_prefix.hpp>// must be the last #include
+
+namespaceboost{
+
+// your code goes here
+
+}
+
+#include <boost/config/abi_suffix.hpp>// pops abi_prefix.hpp pragmas
+
+#endif// include guard
+
+
+ my_library.cpp
+
+
+...
+// nothing special need be done in the implementation file
+...
+
+
+ The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS,
+ or they can define BOOST_ABI_PREFIX
+ and/or BOOST_ABI_SUFFIX
+ to point to their own prefix/suffix headers if they so wish.
+
+ It is essential that users link to a build of a library which was built
+ against the same runtime library that their application will be built against
+ -if this does not happen then the library will not be binary compatible
+ with their own code- and there is a high likelihood that their application
+ will experience runtime crashes. These kinds of problems can be extremely
+ time consuming and difficult to debug, and often lead to frustrated users
+ and authors alike (simply selecting the right library to link against is
+ not as easy as it seems when their are 6-8 of them to chose from, and some
+ users seem to be blissfully unaware that there even are different runtimes
+ available to them).
+
+
+ To solve this issue, some compilers allow source code to contain #pragma's that instruct the linker
+ which library to link against, all the user need do is include the headers
+ they need, place the compiled libraries in their library search path, and
+ the compiler and linker do the rest. Boost.config supports this via the
+ header <boost/config/auto_link.hpp>, before including this header one or
+ more of the following macros need to be defined:
+
+
+
+
+
BOOST_LIB_NAME
+
+ Required: An identifier containing the basename of the library, for
+ example 'boost_regex'.
+
+
BOOST_DYN_LINK
+
+ Optional: when set link to dll rather than static library.
+
+
BOOST_LIB_DIAGNOSTIC
+
+ Optional: when set the header will print out the name of the library
+ selected (useful for debugging).
+
+
+
+
+ If the compiler supports this mechanism, then it will be told to link against
+ the appropriately named library, the actual algorithm used to mangle the
+ name of the library is documented inside <boost/config/auto_link.hpp>
+ and has to match that used to create the libraries via bjam 's install
+ rules.
+
+
+ my_library.hpp
+
+
+...
+//
+// Don't include auto-linking code if the user has disabled it by
+// defining BOOST_ALL_NO_LIB, or BOOST_MY_LIBRARY_NO_LIB, or if this
+// is one of our own source files (signified by BOOST_MY_LIBRARY_SOURCE):
+//
+#if!defined(BOOST_ALL_NO_LIB)&&!defined(BOOST_MY_LIBRARY_NO_LIB)&&!defined(BOOST_MY_LIBRARY_SOURCE)
+# defineBOOST_LIB_NAMEboost_my_library
+# ifdefBOOST_MY_LIBRARY_DYN_LINK
+# defineBOOST_DYN_LINK
+# endif
+# include<boost/config/auto_link.hpp>
+#endif
+...
+
+
+ my_library.cpp
+
+
+// define BOOST_MY_LIBRARY_SOURCE so that the header knows that the
+// library is being built (possibly exporting rather than importing code)
+//
+#defineBOOST_MY_LIBRARY_SOURCE
+
+#include<boost/my_library/my_library.hpp>
+...
+
+ The <boost/config.hpp>
+ header is used to pass configuration information to other boost files, allowing
+ them to cope with platform dependencies such as arithmetic byte ordering, compiler
+ pragmas, or compiler shortcomings. Without such configuration information,
+ many current compilers would not work with the Boost libraries.
+
+
+ Centralizing configuration information in this header reduces the number of
+ files that must be modified when porting libraries to new platforms, or when
+ compilers are updated. Ideally, no other files would have to be modified when
+ porting to a new platform.
+
+
+ Configuration headers are controversial because some view them as condoning
+ broken compilers and encouraging non-standard subsets. Adding settings for
+ additional platforms and maintaining existing settings can also be a problem.
+ In other words, configuration headers are a necessary evil rather than a desirable
+ feature. The boost config.hpp policy is designed to minimize the problems and
+ maximize the benefits of a configuration header.
+
+
+ Note that:
+
+
+
+ Boost library implementers are not required to "#include
+ <boost/config.hpp>",
+ and are not required in any way to support compilers that do not comply with
+ the C++ Standard (ISO/IEC 14882).
+
+
+ If a library implementer wishes to support some non-conforming compiler,
+ or to support some platform specific feature, "#include
+ <boost/config.hpp>"
+ is the preferred way to obtain configuration information not available from
+ the standard headers such as <climits>,
+ etc.
+
+
+ If configuration information can be deduced from standard headers such as
+ <climits>, use those standard headers rather than
+ <boost/config.hpp>.
+
+
+ Boost files that use macros defined in <boost/config.hpp>
+ should have sensible, standard conforming, default behavior if the macro
+ is not defined. This means that the starting point for porting <boost/config.hpp>
+ to a new platform is simply to define nothing at all specific to that platform.
+ In the rare case where there is no sensible default behavior, an #error message
+ should describe the problem.
+
+
+ If a Boost library implementer wants something added to config.hpp, post
+ a request on the Boost mailing list. There is no guarantee such a request
+ will be honored; the intent is to limit the complexity of config.hpp.
+
+
+ The intent is to support only compilers which appear on their way to becoming
+ C++ Standard compliant, and only recent releases of those compilers at that.
+
+
+ The intent is not to disable mainstream features now well-supported by the
+ majority of compilers, such as namespaces, exceptions, RTTI, or templates.
+
+ When you need to add a new defect macro -either to fix a problem with an
+ existing library, or when adding a new library- distil the issue down to
+ a simple test case; often, at this point other (possibly better) workarounds
+ may become apparent. Secondly always post the test case code to the boost
+ mailing list and invite comments; remember that C++ is complex and that sometimes
+ what may appear a defect, may in fact turn out to be a problem with the authors
+ understanding of the standard.
+
+
+ When you name the macro, follow the BOOST_NO_SOMETHING
+ naming convention, so that it's obvious that this is a macro reporting a
+ defect.
+
+
+ Finally, add the test program to the regression tests. You will need to place
+ the test case in a .ipp
+ file with the following comments near the top:
+
+
+// MACRO: BOOST_NO_FOO
+// TITLE: foo
+// DESCRIPTION: If the compiler fails to support foo
+
+
+ These comments are processed by the autoconf script, so make sure the format
+ follows the one given. The file should be named "boost_no_foo.ipp",
+ where foo is the defect description -try and keep the file name under the
+ Mac 30 character filename limit though. You will also need to provide a function
+ prototype "inttest()" that is declared in a namespace with
+ the same name as the macro, but in all lower case, and which returns zero
+ on success:
+
+ Once the test code is in place in libs/config/test, updating the configuration
+ test system proceeds as:
+
+
+
+ cd into libs/config/tools and run bjam
+ --v2
+ : this generates the .cpp
+ file test cases from the .ipp file, updates the Jamfile, config_test.cpp and config_info.cpp.
+
+
+ cd into libs/config/test and run bjam
+ --v2
+ MACRONAMEcompiler-list
+ : where MACRONAME is the name of the new macro, and
+ compiler-list is the list of compilers to test
+ with. You should see the tests pass with those compilers that don't have
+ the defect, and fail with those that do.
+
+
+ cd into libs/config/test and run
+ bjam--v2config_info
+ config_testcompiler-list
+ : config_info should build
+ and run cleanly for all the compilers in compiler-list
+ while config_test should
+ fail for those that have the defect, and pass for those that do not.
+
+
+
+ Then you should:
+
+
+
+ Define the defect macro in those config headers that require it.
+
+
+ Document the macro in this documentation (please do not forget this step!!)
+
+
+ Commit everything.
+
+
+ Keep an eye on the regression tests for new failures in Boost.Config caused
+ by the addition.
+
+ When you need to add a macro that describes a feature that the standard does
+ not require, follow the convention for adding a new defect macro (above),
+ but call the macro BOOST_HAS_FOO,
+ and name the test file "boost_has_foo.ipp".
+ Try not to add feature test macros unnecessarily, if there is a platform
+ specific macro that can already be used (for example _WIN32,
+ __BEOS__, or __linux) to identify the feature then use
+ that. Try to keep the macro to a feature group, or header name, rather than
+ one specific API (for example BOOST_HAS_NL_TYPES_H
+ rather than BOOST_HAS_CATOPEN).
+ If the macro describes a POSIX feature group, then add boilerplate code to
+ <boost/config/suffix.hpp>
+ to auto-detect the feature where possible (if you are wondering why we can't
+ use POSIX feature test macro directly, remember that many of these features
+ can be added by third party libraries, and are not therefore identified inside
+ <unistd.h>).
+
+ The aim of boost's configuration setup is that the configuration headers
+ should be relatively stable - a boost user should not have to recompile their
+ code just because the configuration for some compiler that they're not interested
+ in has changed. Separating the configuration into separate compiler/standard
+ library/platform sections provides for part of this stability, but boost
+ authors require some amount of restraint as well, in particular:
+
+ <boost/config/suffix.hpp>
+ is always included so be careful about modifying this file as it breaks dependencies
+ for everyone. This file should include only "boilerplate" configuration
+ code, and generally should change only when new macros are added.
+
+ The compiler/platform/standard library selection code is set up so that unknown
+ platforms are ignored and assumed to be fully standards compliant -this gives
+ unknown platforms a "sporting chance" of working "as is"
+ even without running the configure script.
+
+
+ When adding or modifying the individual mini-configs, assume that future,
+ as yet unreleased versions of compilers, have all the defects of the current
+ version. Although this is perhaps unnecessarily pessimistic, it cuts down
+ on the maintenance of these files, and experience suggests that pessimism
+ is better placed than optimism here!
+
+ The problem with many traditional "textbook" implementations of configuration
+ headers (where all the configuration options are in a single "monolithic"
+ header) is that they violate certain fundamental software engineering principles
+ which would have the effect of making boost more fragile, more difficult to
+ maintain and more difficult to use safely. You can find a description of the
+ principles from the following
+ article.
+
+ Consider a situation in which you are concurrently developing on multiple
+ platforms. Then consider adding a new platform or changing the platform definitions
+ of an existing platform. What happens? Everything, and this does literally
+ mean everything, recompiles. Isn't it quite absurd that adding a new platform,
+ which has absolutely nothing to do with previously existing platforms, means
+ that all code on all existing platforms needs to be recompiled?
+
+
+ Effectively, there is an imposed physical dependency between platforms that
+ have nothing to do with each other. Essentially, the traditional solution
+ employed by configuration headers does not conform to the Open-Closed Principle:
+
+
+
+
+
+ "A module should be open for extension but
+ closed for modification."
+
+
+
+
+
+ Extending a traditional configuration header implies modifying existing code.
+
+
+ Furthermore, consider the complexity and fragility of the platform detection
+ code. What if a simple change breaks the detection on some minor platform?
+ What if someone accidentally or on purpose (as a workaround for some other
+ problem) defines some platform dependent macros that are used by the detection
+ code? A traditional configuration header is one of the most volatile headers
+ of the entire library, and more stable elements of Boost would depend on
+ it. This violates the Stable Dependencies Principle:
+
+
+
+
+
+ "Depend in the direction of stability."
+
+
+
+
+
+ After even a minor change to a traditional configuration header on one minor
+ platform, almost everything on every platform should be tested if we follow
+ sound software engineering practice.
+
+
+ Another important issue is that it is not always possible to submit changes
+ to <boost/config.hpp>.
+ Some boost users are currently working on platforms using tools and libraries
+ that are under strict Non-Disclosure Agreements. In this situation it is
+ impossible to submit changes to a traditional monolithic configuration header,
+ instead some method by which the user can insert their own configuration
+ code must be provided.
+
+ The approach taken by boost's configuration headers is to separate configuration
+ into three orthogonal parts: the compiler, the standard library and the platform.
+ Each compiler/standard library/platform gets its own mini-configuration header,
+ so that changes to one compiler's configuration (for example) does not affect
+ other compilers. In addition there are measures that can be taken both to
+ omit the compiler/standard library/platform detection code (so that adding
+ support to a new platform does not break dependencies), or to freeze the
+ configuration completely; providing almost complete protection against dependency
+ changes.
+
+ Distributed under the Boost Software License, Version 1.0. (See accompanying
+ file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+
+ Boost comes already configured for most common compilers and platforms; you
+ should be able to use boost "as is". Since the compiler is configured
+ separately from the standard library, the default configuration should work
+ even if you replace the compiler's standard library with a third-party standard
+ library (like STLport).
+
+
+ Using boost "as is" without trying to reconfigure is the recommended
+ method for using boost. You can, however, run the configure script if you
+ want to, and there are regression tests provided that allow you to test the
+ current boost configuration with your particular compiler setup.
+
+
+ Boost library users can request support for additional compilers or platforms
+ by visiting our Tracker
+ and submitting a support request.
+
+ While Boost library users are not required to include that file directly,
+ or use those configuration macros, such use is acceptable. The configuration
+ macros are documented as to their purpose, usage, and limitations which makes
+ them usable by both Boost library and user code.
+
+
+ Boost informational or helper
+ macros are designed for use by Boost users as well as for our own internal
+ use. Note however, that the feature test
+ and defect test macros were designed
+ for internal use by Boost libraries, not user code, so they can change at
+ any time (though no gratuitous changes are made to them). Boost library problems
+ resulting from changes to the configuration macros are caught by the Boost
+ regression tests, so the Boost libraries are updated to account for those
+ changes. By contrast, Boost library user code can be adversely affected by
+ changes to the macros without warning. The best way to keep abreast of changes
+ to the macros used in user code is to monitor the discussions on the Boost
+ developers list.
+
+ This configure script only sets up the Boost headers for use with a particular
+ compiler. It has no effect on Boost.Build, or how the libraries are built.
+
+
+
+ If you know that boost is incorrectly configured for your particular setup,
+ and you are on a UNIX like platform, then you may want to try and improve
+ things by running the boost configure script. From a shell command prompt
+ you will need to cd into <boost-root>/libs/config/
+ and type:
+
+
+
+
+
+ sh./configure
+
+
+
+
+
+ you will see a list of the items being checked as the script works its way
+ through the regression tests. Note that the configure script only really
+ auto-detects your compiler if it's called g++, c++ or CC. If you are using
+ some other compiler you will need to set one or more of the following environment
+ variables:
+
+
+
+
+
+
+
+
+
+ Variable
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ CXX
+
+
+
+
+ The name of the compiler, for example c++.
+
+
+
+
+
+
+ CXXFLAGS
+
+
+
+
+ The compiler flags to use, for example -O2.
+
+
+
+
+
+
+ LDFLAGS
+
+
+
+
+ The linker flags to use, for example -L/mypath.
+
+
+
+
+
+
+ LIBS
+
+
+
+
+ Any libraries to link in, for example -lpthread.
+
+
+
+
+
+
+ For example to run the configure script with HP aCC, you might use something
+ like:
+
+ However you run the configure script, when it finishes you will find a new
+ header -user.hpp- located in the <boost-root>/libs/config/
+ directory. Note that configure does not install this
+ header into your boost include path by default. This header contains
+ all the options generated by the configure script, plus a header-section
+ that contains the user settable options from the default version of <boost/config/user.hpp>
+ (located under <boost-root>/boost/config/).
+ There are two ways you can use this header:
+
+
+
+Option 1: copy the header into <boost-root>/boost/config/ so that it replaces the default user.hpp
+ provided by boost. This option allows only one configure-generated setup;
+ boost developers should avoid this option, as it incurs the danger of accidentally
+ committing a configure-modified <boost/config/user.hpp>
+ to the cvs repository (something you will not be thanked for!).
+
+
+Option 2: give the header a more memorable
+ name, and place it somewhere convenient; then, define the macro BOOST_USER_CONFIG to point to it. For
+ example create a new sub-directory <boost-root>/boost/config/user/, and copy the header there; for example
+ as multithread-gcc-config.hpp. Then, when compiling add the command
+ line option: -DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>",
+ and boost will use the new configuration header. This option allows you
+ to generate more than one configuration header, and to keep them separate
+ from the boost source - so that updates to the source do not interfere
+ with your configuration.
+
+ There are some configuration-options that represent user choices, rather
+ than compiler defects or platform specific options. These are listed in
+ <boost/config/user.hpp>
+ and at the start of a configure-generated user.hpp header.
+ You can define these on the command line, or by editing <boost/config/user.hpp>, they are listed in the following table:
+
+
+
+
+
+
+
+
+
+ Macro
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ BOOST_USER_CONFIG
+
+
+
+
+ When defined, it should point to the name of the user configuration
+ file to include prior to any boost configuration files. When not
+ defined, defaults to <boost/config/user.hpp>.
+
+
+
+
+
+
+ BOOST_COMPILER_CONFIG
+
+
+
+
+ When defined, it should point to the name of the compiler configuration
+ file to use. Defining this cuts out the compiler selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are using gcc, then you could define BOOST_COMPILER_CONFIG
+ to <boost/config/compiler/gcc.hpp>.
+
+
+
+
+
+
+ BOOST_STDLIB_CONFIG
+
+
+
+
+ When defined, it should point to the name of the standard library
+ configuration file to use. Defining this cuts out the standard library
+ selection logic, and eliminates the dependency on the header containing
+ that logic. For example if you are using STLport, then you could
+ define BOOST_STDLIB_CONFIG
+ to <boost/config/stdlib/stlport.hpp>.
+
+
+
+
+
+
+ BOOST_PLATFORM_CONFIG
+
+
+
+
+ When defined, it should point to the name of the platform configuration
+ file to use. Defining this cuts out the platform selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are compiling on linux, then you could define
+ BOOST_PLATFORM_CONFIG
+ to <boost/config/platform/linux.hpp>.
+
+
+
+
+
+
+ BOOST_NO_COMPILER_CONFIG
+
+
+
+
+ When defined, no compiler configuration file is selected or included,
+ define when the compiler is fully conformant with the standard, or
+ where the user header (see BOOST_USER_CONFIG),
+ has had any options necessary added to it, for example by an autoconf
+ generated configure script.
+
+
+
+
+
+
+ BOOST_NO_STDLIB_CONFIG
+
+
+
+
+ When defined, no standard library configuration file is selected
+ or included, define when the standard library is fully conformant
+ with the standard, or where the user header (see BOOST_USER_CONFIG),
+ has had any options necessary added to it, for example by an autoconf
+ generated configure script.
+
+
+
+
+
+
+ BOOST_NO_PLATFORM_CONFIG
+
+
+
+
+ When defined, no platform configuration file is selected or included,
+ define when the platform is fully conformant with the standard (and
+ has no useful extra features), or where the user header (see BOOST_USER_CONFIG), has had any
+ options necessary added to it, for example by an autoconf generated
+ configure script.
+
+
+
+
+
+
+ BOOST_NO_CONFIG
+
+
+
+
+ Equivalent to defining all of BOOST_NO_COMPILER_CONFIG,
+ BOOST_NO_STDLIB_CONFIG
+ and BOOST_NO_PLATFORM_CONFIG.
+
+
+
+
+
+
+ BOOST_STRICT_CONFIG
+
+
+
+
+ The normal behavior for compiler versions that are newer than the
+ last known version, is to assume that they have all the same defects
+ as the last known version. By setting this define, then compiler
+ versions that are newer than the last known version are assumed to
+ be fully conforming with the standard. This is probably most useful
+ for boost developers or testers, and for those who want to use boost
+ to test beta compiler versions.
+
+
+
+
+
+
+ BOOST_ASSERT_CONFIG
+
+
+
+
+ When this flag is set, if the config finds anything unknown, then
+ it will stop with a #error rather than continue. Boost regression
+ testers should set this define, as should anyone who wants to quickly
+ check whether boost is supported on their platform.
+
+
+
+
+
+
+ BOOST_DISABLE_THREADS
+
+
+
+
+ When defined, disables threading support, even if the compiler in
+ its current translation mode supports multiple threads.
+
+
+
+
+
+
+ BOOST_DISABLE_WIN32
+
+
+
+
+ When defined, disables the use of Win32 specific API's, even when
+ these are available. Also has the effect of setting BOOST_DISABLE_THREADS unless BOOST_HAS_PTHREADS is set. This
+ option may be set automatically by the config system when it detects
+ that the compiler is in "strict mode".
+
+
+
+
+
+
+ BOOST_DISABLE_ABI_HEADERS
+
+
+
+
+ Stops boost headers from including any prefix/suffix headers that
+ normally control things like struct packing and alignment.
+
+
+
+
+
+
+ BOOST_ABI_PREFIX
+
+
+
+
+ A prefix header to include in place of whatever boost.config would
+ normally select, any replacement should set up struct packing and
+ alignment options as required.
+
+
+
+
+
+
+ BOOST_ABI_SUFFIX
+
+
+
+
+ A suffix header to include in place of whatever boost.config would
+ normally select, any replacement should undo the effects of the prefix
+ header.
+
+
+
+
+
+
+ BOOST_ALL_DYN_LINK
+
+
+
+
+ Forces all libraries that have separate source, to be linked as dll's
+ rather than static libraries on Microsoft Windows (this macro is
+ used to turn on __declspec(dllimport) modifiers, so that the compiler
+ knows which symbols to look for in a dll rather than in a static
+ library). Note that there may be some libraries that can only be
+ statically linked (Boost.Test for example) and others which may only
+ be dynamically linked (Boost.Threads for example), in these cases
+ this macro has no effect.
+
+
+
+
+
+
+ BOOST_WHATEVER_DYN_LINK
+
+
+
+
+ Forces library "whatever" to be linked as a dll rather
+ than a static library on Microsoft Windows: replace the WHATEVER
+ part of the macro name with the name of the library that you want
+ to dynamically link to, for example use BOOST_DATE_TIME_DYN_LINK
+ or BOOST_REGEX_DYN_LINK
+ etc (this macro is used to turn on __declspec(dllimport) modifiers, so that the compiler
+ knows which symbols to look for in a dll rather than in a static
+ library). Note that there may be some libraries that can only be
+ statically linked (Boost.Test for example) and others which may only
+ be dynamically linked (Boost.Threads for example), in these cases
+ this macro is unsupported.
+
+
+
+
+
+
+ BOOST_ALL_NO_LIB
+
+
+
+
+ Tells the config system not to automatically select which libraries
+ to link against. Normally if a compiler supports #pragma lib, then
+ the correct library build variant will be automatically selected
+ and linked against, simply by the act of including one of that library's
+ headers. This macro turns that feature off.
+
+
+
+
+
+
+ BOOST_WHATEVER_NO_LIB
+
+
+
+
+ Tells the config system not to automatically select which library
+ to link against for library "whatever", replace WHATEVER
+ in the macro name with the name of the library; for example BOOST_DATE_TIME_NO_LIB or BOOST_REGEX_NO_LIB. Normally if
+ a compiler supports #pragma
+ lib, then the correct library
+ build variant will be automatically selected and linked against,
+ simply by the act of including one of that library's headers. This
+ macro turns that feature off.
+
+
+
+
+
+
+ BOOST_LIB_DIAGNOSTIC
+
+
+
+
+ Causes the auto-linking code to output diagnostic messages indicating
+ the name of the library that is selected for linking.
+
+
+
+
+
+
+ BOOST_LIB_TOOLSET
+
+
+
+
+ Overrides the name of the toolset part of the name of library being
+ linked to; note if defined this must be defined to a quoted string
+ literal, for example "abc".
+
+ By setting various macros on the compiler command line or by editing <boost/config/user.hpp>,
+ the boost configuration setup can be optimised in a variety of ways.
+
+
+ Boost's configuration is structured so that the user-configuration is included
+ first (defaulting to <boost/config/user.hpp>
+ if BOOST_USER_CONFIG is not
+ defined). This sets up any user-defined policies, and gives the user-configuration
+ a chance to influence what happens next.
+
+
+ Next the compiler, standard library, and platform configuration files are
+ included. These are included via macros (BOOST_COMPILER_CONFIG
+ etc, see user settable macros),
+ and if the corresponding macro is undefined then a separate header that detects
+ which compiler/standard library/platform is in use is included in order to
+ set these. The config can be told to ignore these headers altogether if the
+ corresponding BOOST_NO_XXX
+ macro is set (for example BOOST_NO_COMPILER_CONFIG
+ to disable including any compiler configuration file - see
+ user settable macros).
+
+
+ Finally the boost configuration header, includes <boost/config/suffix.hpp>;
+ this header contains any boiler plate configuration code - for example where
+ one boost macro being set implies that another must be set also.
+
+
+ The following usage examples represent just a few of the possibilities:
+
+ Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0.
+ Lets suppose also that we don't intend to update our compiler or standard
+ library any time soon. In order to avoid breaking dependencies when we
+ update boost, we may want to "freeze" our configuration headers,
+ so that we only have to rebuild our project if the boost code itself has
+ changed, and not because the boost config has been updated for more recent
+ versions of Visual C++ or STLport. We'll start by realising that the configuration
+ files in use are: <boost/config/compiler/visualc.hpp> for the compiler, <boost/config/stdlib/stlport.hpp> for the standard library, and
+ <boost/config/platform/win32.hpp> for the platform. Next we'll
+ create our own private configuration directory: boost/config/mysetup/, and copy the configuration files into
+ there. Finally, open up <boost/config/user.hpp>
+ and edit the following defines:
+
+ Now when you use boost, its configuration header will go straight to our
+ "frozen" versions, and ignore the default versions, you will
+ now be insulated from any configuration changes when you update boost.
+ This technique is also useful if you want to modify some of the boost configuration
+ files; for example if you are working with a beta compiler release not
+ yet supported by boost.
+
+ Lets suppose that you're using boost with a compiler that is fully conformant
+ with the standard; you're not interested in the fact that older versions
+ of your compiler may have had bugs, because you know that your current
+ version does not need any configuration macros setting. In a case like
+ this, you can define BOOST_NO_COMPILER_CONFIG
+ either on the command line, or in <boost/config/user.hpp>,
+ and miss out the compiler configuration header altogether (actually you
+ miss out two headers, one which works out what the compiler is, and one
+ that configures boost for it). This has two consequences: the first is
+ that less code has to be c ompiled, and the second that you have removed
+ a dependency on two boost headers.
+
+ If you are working on a unix-like platform then you can use the configure
+ script to generate a "frozen" configuration based on your current
+ compiler setup - see using the configure
+ script for more details.
+
+ The boost configuration library provides a full set of regression test programs
+ under the <boost-root>/boost/config/
+ test/
+ sub-directory:
+
+
+
+
+
+
+
+
+
+ File
+
+
+
+
+ Description
+
+
+
+
+
+
+
+ config_info.cpp
+
+
+
+
+ Prints out a detailed description of your compiler/standard library/platform
+ setup, plus your current boost configuration. The information provided
+ by this program useful in setting up the boost configuration files.
+ If you report that boost is incorrectly configured for your compiler/library/platform
+ then please include the output from this program when reporting the
+ changes required.
+
+
+
+
+
+
+ config_test.cpp
+
+
+
+
+ A monolithic test program that includes most of the individual test
+ cases. This provides a quick check to see if boost is correctly configured
+ for your compiler/library/platform.
+
+
+
+
+
+
+ limits_test.cpp
+
+
+
+
+ Tests your standard library's std::numeric_limits
+ implementation (or its boost provided replacement if BOOST_NO_LIMITS is defined). This
+ test file fails with most versions of numeric_limits, mainly due
+ to the way that some compilers treat NAN's and infinity.
+
+
+
+
+
+
+ no_*pass.cpp
+
+
+
+
+ Individual compiler defect test files. Each of these should compile,
+ if one does not then the corresponding BOOST_NO_XXX
+ macro needs to be defined - see each test file for specific details.
+
+
+
+
+
+
+ no_*fail.cpp
+
+
+
+
+ Individual compiler defect test files. Each of these should not compile,
+ if one does then the corresponding BOOST_NO_XXX
+ macro is defined when it need not be - see each test file for specific
+ details.
+
+
+
+
+
+
+ has_*pass.cpp
+
+
+
+
+ Individual feature test files. If one of these does not compile then
+ the corresponding BOOST_HAS_XXX
+ macro is defined when it should not be - see each test file for specific
+ details.
+
+
+
+
+
+
+ has_*fail.cpp
+
+
+
+
+ Individual feature test files. If one of these does compile then
+ the corresponding BOOST_HAS_XXX
+ macro can be safely defined - see each test file for specific details.
+
+
+
+
+
+
+ Although you can run the configuration regression tests as individual test
+ files, there are rather a lot of them, so there are a couple of shortcuts
+ to help you out:
+
+
+ If you have built the boost
+ regression test driver, then you can use this to produce a nice html
+ formatted report of the results using the supplied test file.
+
+
+ Alternatively you can run the configure script like this:
+
+
+
+
+
+ ./configure
+ --enable-test
+
+
+
+
+
+ in which case the script will test the current configuration rather than
+ creating a new one from scratch.
+
+
+ If you are reporting the results of these tests for a new platform/library/compiler
+ then please include a log of the full compiler output, the output from config_info.cpp, and the pass/fail test results.
+
+
+
+
+
+
+
+
Last revised: November 07, 2007 at 17:16:43 GMT
+
+
+
+
+
+
diff --git a/doc/macro_reference.qbk b/doc/macro_reference.qbk
new file mode 100644
index 00000000..546d1a7b
--- /dev/null
+++ b/doc/macro_reference.qbk
@@ -0,0 +1,840 @@
+[/
+ Boost.Config
+
+ Copyright (c) 2001 Beman Dawes
+ Copyright (c) 2001 Vesa Karvonen
+ Copyright (c) 2001 John Maddock
+
+ Distributed under the Boost Software License, Version 1.0.
+ (See accompanying file LICENSE_1_0.txt or copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+]
+
+
+
+[section Boost Macro Reference]
+
+[#config_defects]
+
+[section Macros that describe defects]
+
+The following macros all describe features that are required by the C++ standard,
+if one of the following macros is defined, then it represents a defect in the
+compiler's conformance with the standard.
+
+
+[table
+[[Macro ][Section ][ Description ]]
+
+
+[[`BOOST_BCB_PARTIAL_SPECIALIZATION_BUG`][Compiler][
+The compiler exibits certain partial specialisation bug - probably Borland
+C++ Builder specific.
+]]
+[[`BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL`][Compiler][
+Argument dependent lookup fails if there is a using declaration for the
+symbol being looked up in the current scope. For example, using
+`boost::get_pointer`; prevents ADL from finding overloads of `get_pointer`
+in namespaces nested inside boost (but not elsewhere). Probably
+Borland specific.
+]]
+[[`BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP`][Compiler][
+Compiler does not implement argument-dependent lookup (also named
+Koenig lookup); see std::3.4.2 \[basic.koenig.lookup\]
+]]
+[[`BOOST_NO_AUTO_PTR`][Standard library][
+If the compiler / library supplies non-standard or broken `std::auto_ptr`.
+]]
+[[`BOOST_NO_CTYPE_FUNCTIONS`][Platform][
+The Platform does not provide functions for the character-classifying
+operations `` and ``, only macros.
+]]
+[[`BOOST_NO_CV_SPECIALIZATIONS`][Compiler][
+If template specialisations for cv-qualified types conflict with a
+specialisation for a cv-unqualififed type.
+]]
+[[`BOOST_NO_CV_VOID_SPECIALIZATIONS`][Compiler][
+If template specialisations for cv-void types conflict with a specialisation
+for void.
+]]
+[[`BOOST_NO_CWCHAR`][Platform][
+The Platform does not provide `` and ``.
+]]
+[[`BOOST_NO_CWCTYPE`][Platform][
+The Platform does not provide `` and ``.
+]]
+[[`BOOST_NO_DEPENDENT_NESTED_DERIVATIONS`][Compiler][
+The compiler fails to compile a nested class that has a dependent base class:
+``
+template
+struct foo : {
+ template
+ struct bar : public U {};
+``
+};
+]]
+[[`BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS`][Compiler][
+Template value parameters cannot have a dependent type, for example:
+``
+template
+class X { ... };
+``
+]]
+[[`BOOST_NO_EXCEPTION_STD_NAMESPACE`][Standard Library][
+The standard library does not put some or all of the contents of
+`` in namespace std.
+]]
+[[`BOOST_NO_EXCEPTIONS`][Compiler][
+The compiler does not support exception handling (this setting is typically
+required by many C++ compilers for embedded platforms). Note that there is
+no requirement for boost libraries to honor this configuration setting -
+indeed doing so may be impossible in some cases. Those libraries that do
+honor this will typically abort if a critical error occurs - you have been
+warned!
+]]
+[[`BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS`][Compiler][
+Can only use deduced template arguments when calling function template
+instantiations.
+]]
+[[`BOOST_NO_FUNCTION_TEMPLATE_ORDERING`][Compiler][
+The compiler does not perform function template ordering or its function
+template ordering is incorrect.
+``
+// #1
+template void f(T);
+
+// #2
+template void f(T(*)(U));
+
+void bar(int);
+
+f(&bar); // should choose #2.
+``
+]]
+[[`BOOST_NO_INCLASS_MEMBER_INITIALIZATION`][Compiler][
+Compiler violates std::9.4.2/4.
+]]
+[[`BOOST_NO_INTRINSIC_WCHAR_T`][Compiler][
+The C++ implementation does not provide `wchar_t`, or it is really a synonym
+for another integral type. Use this symbol to decide whether it is appropriate
+to explicitly specialize a template on `wchar_t` if there is already a
+specialization for other integer types.
+]]
+[[`BOOST_NO_IOSFWD`][std lib][
+The standard library lacks ``.
+]]
+[[`BOOST_NO_IOSTREAM`][std lib][
+The standard library lacks ``, `` or ``.
+]]
+[[`BOOST_NO_IS_ABSTRACT`][Compiler][
+The C++ compiler does not support SFINAE with abstract types, this is covered
+by __CORE_LANGUAGE_DR337__, but is not part of the current standard. Fortunately
+most compilers that support SFINAE also support this DR.
+]]
+[[`BOOST_NO_LIMITS`][Standard library][
+The C++ implementation does not provide the `` header. Never check for
+this symbol in library code; always include ``, which
+guarantees to provide `std::numeric_limits`.
+]]
+[[`BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS`][Standard library][
+Constants such as `numeric_limits::is_signed` are not available for use
+at compile-time.
+]]
+[[`BOOST_NO_LONG_LONG_NUMERIC_LIMITS`][Standard library][
+There is no specialization for `numeric_limits` and
+`numeric_limits`. `` will then add these
+specializations as a standard library "fix" only if the compiler supports the
+`long long` datatype.
+]]
+[[`BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS`][Compiler][
+The compiler does not support the specialization of individual member
+functions of template classes.
+]]
+[[`BOOST_NO_MEMBER_TEMPLATE_KEYWORD`][Compiler][
+If the compiler supports member templates, but not the template keyword
+when accessing member template classes.
+]]
+[[`BOOST_NO_MEMBER_TEMPLATE_FRIENDS`][Compiler][
+Member template friend syntax (`template friend class frd;`)
+described in the C++ Standard, 14.5.3, not supported.
+]]
+[[`BOOST_NO_MEMBER_TEMPLATES`][Compiler][
+Member template functions not fully supported.
+]]
+[[`BOOST_NO_MS_INT64_NUMERIC_LIMITS`][Standard library][
+There is no specialization for `numeric_limits<__int64>` and
+`numeric_limits`. `` will then add these
+specializations as a standard library "fix", only if the compiler supports
+the `__int64` datatype.
+]]
+[[`BOOST_NO_OPERATORS_IN_NAMESPACE`][Compiler][
+Compiler requires inherited operator friend functions to be defined at
+namespace scope, then using'ed to boost. Probably GCC specific. See
+[@../../../../boost/operators.hpp ``] for example.
+]]
+[[`BOOST_NO_POINTER_TO_MEMBER_CONST`][Compiler][
+The compiler does not correctly handle pointers to const member functions,
+preventing use of these in overloaded function templates. See
+[@../../../../boost/functional.hpp ``] for example.
+]]
+[[`BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS`][Compiler][
+Pointers to members don't work when used as template parameters.
+]]
+[[`BOOST_NO_PRIVATE_IN_AGGREGATE`][Compiler][
+The compiler misreads 8.5.1, treating classes as non-aggregate if they
+contain private or protected member functions.
+]]
+[[`BOOST_NO_SFINAE`][Compiler][
+The compiler does not support the "Substitution Failure Is Not An Error"
+meta-programming idiom.
+]]
+[[`BOOST_NO_STD_ALLOCATOR`][Standard library][
+The C++ standard library does not provide a standards conforming
+`std::allocator`.
+]]
+[[`BOOST_NO_STD_DISTANCE`][Standard library][
+The platform does not have a conforming version of `std::distance`.
+]]
+[[`BOOST_NO_STD_ITERATOR`][Standard library][
+The C++ implementation fails to provide the `std::iterator` class.
+]]
+[[`BOOST_NO_STD_ITERATOR_TRAITS`][Standard library][
+The compiler does not provide a standard compliant implementation of
+`std::iterator_traits`. Note that the compiler may still have a
+non-standard implementation.
+]]
+[[`BOOST_NO_STD_LOCALE`][Standard library][
+The standard library lacks `std::locale`.
+]]
+[[`BOOST_NO_STD_MESSAGES`][Standard library][
+The standard library lacks a conforming `std::messages` facet.
+]]
+[[`BOOST_NO_STD_MIN_MAX`][Standard library][
+The C++ standard library does not provide the `min()` and `max()` template
+functions that should be in ``.
+]]
+[[`BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN`][Standard library][
+Defined if the standard library's output iterators are not assignable.
+]]
+[[`BOOST_NO_STD_TYPEINFO`][Standard library][
+The header declares `type_info` in the global namespace instead of namespace std.
+]]
+[[`BOOST_NO_STD_USE_FACET`][Standard library][
+The standard library lacks a conforming `std::use_facet`.
+]]
+[[`BOOST_NO_STD_WSTREAMBUF`][Standard library][
+The standard library's implementation of `std::basic_streambuf`
+is either missing, incomplete, or buggy.
+]]
+[[`BOOST_NO_STD_WSTRING`][Standard library][
+The standard library lacks `std::wstring`.
+]]
+[[`BOOST_NO_STDC_NAMESPACE`][Compiler, Platform][
+The contents of C++ standard headers for C library functions
+(the `` headers) have not been placed in namespace std. This test is
+difficult - some libraries "fake" the std C functions by adding using
+declarations to import them into namespace std, unfortunately they don't
+necessarily catch all of them...
+]]
+[[`BOOST_NO_STRINGSTREAM`][Standard library][
+The C++ implementation does not provide the `` header.
+]]
+[[`BOOST_NO_SWPRINTF`][Platform][
+The platform does not have a conforming version of `swprintf`.
+]]
+[[`BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION`][Compiler][
+Class template partial specialization (14.5.4 \[temp.class.spec\]) not
+supported.
+]]
+[[`BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS`][Standard library][
+The standard library does not provide templated iterator constructors
+for its containers.
+]]
+[[`BOOST_NO_TEMPLATE_TEMPLATES`][Compiler][
+The compiler does not support template template parameters.
+]]
+[[`BOOST_NO_TYPEID`][Compiler][
+The compiler does not support the typeid operator at all.
+]]
+[[`BOOST_NO_UNREACHABLE_RETURN_DETECTION`][Compiler][
+If a return is unreachable, then no return statement should be required,
+however some compilers insist on it, while other issue a bunch of warnings
+if it is in fact present.
+]]
+[[`BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE`][Compiler][
+The compiler will not accept a using declaration that brings a function
+from a typename used as a base class into a derived class if functions of
+the same name are present in the derived class.
+]]
+[[`BOOST_NO_USING_TEMPLATE`][Compiler][
+The compiler will not accept a using declaration that imports a template
+class or function from another namespace. Originally a Borland specific
+problem with imports to/from the global namespace, extended to MSVC6
+which has a specific issue with importing template classes (but not
+functions).
+]]
+[[`BOOST_NO_VOID_RETURNS`][Compiler][
+The compiler does not allow a void function to return the result of calling
+another void function.
+``
+void f() {}
+void g() { return f(); }
+``
+]]
+]
+
+[endsect]
+
+[#config_features]
+
+[section Macros that describe optional features]
+
+The following macros describe features that are not required by the C++
+standard. The macro is only defined if the feature is present.
+
+
+[table
+[[Macro ][Section ][Description ]]
+
+[[`BOOST_HAS_BETHREADS`][Platform][
+The platform supports BeOS style threads.
+]]
+[[`BOOST_HAS_CLOCK_GETTIME`][Platform][
+The platform has the POSIX API `clock_gettime`.
+]]
+[[`BOOST_HAS_DECLSPEC`][Compiler][
+The compiler uses `__declspec(dllexport)` and `__declspec(dllimport)` to
+export/import symbols from dll's.
+]]
+[[`BOOST_HAS_DIRENT_H`][Platform][
+The platform has the POSIX header ``.
+]]
+[[`BOOST_HAS_EXPM1`][Platform][
+The platform has the functions `expm1`, `expm1f` and `expm1l` in ``
+]]
+[[`BOOST_HAS_FTIME`][Platform][
+The platform has the Win32 API `GetSystemTimeAsFileTime`.
+]]
+[[`BOOST_HAS_GETTIMEOFDAY`][Platform][
+The platform has the POSIX API `gettimeofday`.
+]]
+[[`BOOST_HAS_HASH`][Standard library][
+The C++ implementation provides the (SGI) hash_set and hash_map classes.
+When defined, `BOOST_HASH_SET_HEADER` and `BOOST_HASH_LIST_HEADER` will contain
+the names of the header needed to access hash_set and hash_map;
+`BOOST_STD_EXTENSION_NAMESPACE` will provide the namespace in which the two
+class templates reside.
+]]
+[[`BOOST_HAS_LOG1P`][Platform][
+The platform has the functions `log1p`, `log1pf` and `log1pl` in ``.
+]]
+[[`BOOST_HAS_MACRO_USE_FACET`][Standard library][
+The standard library lacks a conforming `std::use_facet`, but has a macro
+`_USE(loc, Type)` that does the job. This is primarily for the Dinkumware
+std lib.
+]]
+[[`BOOST_HAS_MS_INT64`][Compiler][
+The compiler supports the `__int64` data type.
+]]
+[[`BOOST_HAS_NANOSLEEP`][Platform][
+The platform has the POSIX API nanosleep.
+]]
+[[`BOOST_HAS_NL_TYPES_H`][Platform][
+The platform has an ``.
+]]
+[[`BOOST_HAS_NRVO`][Compiler][
+Indicated that the compiler supports the named return value optimization
+(NRVO). Used to select the most efficient implementation for some function.
+See [@../../../../boost/operators.hpp ``] for example.
+]]
+[[`BOOST_HAS_PARTIAL_STD_ALLOCATOR`][Standard Library][
+The standard library has a partially conforming `std::allocator` class, but
+without any of the member templates.
+]]
+[[`BOOST_HAS_PTHREAD_DELAY_NP`][Platform][
+The platform has the POSIX API `pthread_delay_np`.
+]]
+[[`BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE`][Platform][
+The platform has the POSIX API `pthread_mutexattr_settype`.
+]]
+[[`BOOST_HAS_PTHREAD_YIELD`][Platform][
+The platform has the POSIX API `pthread_yield`.
+]]
+[[`BOOST_HAS_PTHREADS`][Platform][
+The platform support POSIX style threads.
+]]
+[[`BOOST_HAS_SCHED_YIELD`][Platform][
+The platform has the POSIX API `sched_yield`.
+]]
+[[`BOOST_HAS_SGI_TYPE_TRAITS`][Compiler, Standard library][
+The compiler has native support for SGI style type traits.
+]]
+[[`BOOST_HAS_STDINT_H`][Platform][
+The platform has a ``
+]]
+[[`BOOST_HAS_SLIST`][Standard library][
+The C++ implementation provides the (SGI) slist class. When defined,
+`BOOST_SLIST_HEADER` will contain the name of the header needed to access
+`slist` and `BOOST_STD_EXTENSION_NAMESPACE` will provide the namespace in
+which `slist` resides.
+]]
+[[`BOOST_HAS_STLP_USE_FACET`][Standard library][
+The standard library lacks a conforming `std::use_facet`, but has a workaround
+class-version that does the job. This is primarily for the STLport std lib.
+]]
+[[`BOOST_HAS_TR1_ARRAY`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_COMPLEX_OVERLOADS`][Standard library][
+The library has a version of `` that supports passing scalars to the
+complex number algorithms.
+]]
+[[`BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG`][Standard library][
+The library has a version of `` that includes the new inverse trig
+functions from TR1.
+]]
+[[`BOOST_HAS_TR1_REFERENCE_WRAPPER`][Standard library][
+The library has TR1 conforming reference wrappers in ``.
+]]
+[[`BOOST_HAS_TR1_RESULT_OF`][Standard library][
+The library has a TR1 conforming result_of template in ``.
+]]
+[[`BOOST_HAS_TR1_MEM_FN`][Standard library][
+The library has a TR1 conforming mem_fn function template in ``.
+]]
+[[`BOOST_HAS_TR1_BIND`][Standard library][
+The library has a TR1 conforming bind function template in ``.
+]]
+[[`BOOST_HAS_TR1_FUNCTION`][Standard library][
+The library has a TR1 conforming function class template in ``.
+]]
+[[`BOOST_HAS_TR1_HASH`][Standard library][
+The library has a TR1 conforming hash function template in ``.
+]]
+[[`BOOST_HAS_TR1_SHARED_PTR`][Standard library][
+The library has a TR1 conforming `shared_ptr` class template in ``.
+]]
+[[`BOOST_HAS_TR1_RANDOM`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_REGEX`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_TUPLE`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_TYPE_TRAITS`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_UTILITY`][Standard library][
+The library has the TR1 additions to `` (tuple interface to `std::pair`).
+]]
+[[`BOOST_HAS_TR1_UNORDERED_MAP`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1_UNORDERED_SET`][Standard library][
+The library has a TR1 conforming version of ``.
+]]
+[[`BOOST_HAS_TR1`][Standard library][
+Implies all the other `BOOST_HAS_TR1_*` macros should be set.
+]]
+[[`BOOST_HAS_THREADS`][Platform, Compiler][
+Defined if the compiler, in its current translation mode, supports multiple
+threads of execution.
+]]
+[[`BOOST_HAS_TWO_ARG_USE_FACET`][Standard library][
+The standard library lacks a conforming std::use_facet, but has a two
+argument version that does the job. This is primarily for the Rogue Wave
+std lib.
+]]
+[[`BOOST_HAS_UNISTD_H`][Platform][
+The Platform provides ``.
+]]
+[[`BOOST_HAS_WINTHREADS`][Platform][
+The platform supports MS Windows style threads.
+]]
+[[`BOOST_MSVC_STD_ITERATOR`][Standard library][
+Microsoft's broken version of `std::iterator` is being used. This implies that
+`std::iterator` takes no more than two template parameters.
+]]
+[[`BOOST_MSVC6_MEMBER_TEMPLATES`][Compiler][
+Microsoft Visual C++ 6.0 has enough member template idiosyncrasies
+(being polite) that `BOOST_NO_MEMBER_TEMPLATES` is defined for this compiler.
+`BOOST_MSVC6_MEMBER_TEMPLATES` is defined to allow compiler specific workarounds.
+This macro gets defined automatically if `BOOST_NO_MEMBER_TEMPLATES` is not
+defined - in other words this is treated as a strict subset of the features
+required by the standard.
+]]
+[[`BOOST_HAS_STDINT_H`][Platform][
+There are no 1998 C++ Standard headers `` or ``, although the
+1999 C Standard does include ``. If `` is present,
+`` can make good use of it, so a flag is supplied (signalling
+presence; thus the default is not present, conforming to the current C++
+standard).
+]]
+]
+
+[endsect]
+
+[section Macros that describe C++0x features]
+
+The following macros describe features that are likely to be included in the
+upcoming ISO C++ standard, C++0x.
+
+
+[table
+[[Macro ][Description ]]
+
+[[`BOOST_HAS_CONCEPTS`][
+The compiler supports concepts. Note: concepts have been proposed for C++0x,
+but have not yet been approved for inclusion in the language.
+]]
+[[`BOOST_HAS_DECLTYPE`][
+The compiler supports decltype.
+]]
+[[`BOOST_HAS_LONG_LONG`][
+The compiler supports the long long data type.
+]]
+[[`BOOST_HAS_RVALUE_REFS`][
+The compiler supports rvalue references.
+]]
+[[`BOOST_HAS_STATIC_ASSERT`][
+The compiler supports static assertions.
+]]
+[[`BOOST_HAS_VARIADIC_TMPL`][
+The compiler supports variadic templates.
+]]
+]
+
+
+[endsect]
+
+[#config_helpers]
+
+[section Boost Helper Macros]
+
+The following macros are either simple helpers, or macros that provide
+workarounds for compiler/standard library defects.
+
+
+[table
+[[Macro ][Description ]]
+
+[[`BOOST_DEDUCED_TYPENAME`][
+Some compilers don't support the use of typename for dependent types in deduced
+contexts. This macro expands to nothing on those compilers, and typename
+elsewhere. For example, replace:
+`template void f(T, typename T::type);`
+with:
+`template void f(T, BOOST_DEDUCED_TYPENAME T::type);`
+]]
+[[`BOOST_HASH_MAP_HEADER`][
+The header to include to get the SGI `hash_map` class. This macro is only
+available if `BOOST_HAS_HASH` is defined.
+]]
+[[`BOOST_HASH_SET_HEADER`][
+The header to include to get the SGI `hash_set` class. This macro is only
+available if `BOOST_HAS_HASH` is defined.
+]]
+[[`BOOST_SLIST_HEADER`][
+The header to include to get the SGI `slist` class. This macro is only
+available if `BOOST_HAS_SLIST` is defined.
+]]
+[[`BOOST_STD_EXTENSION_NAMESPACE`][
+The namespace used for std library extensions (hashtable classes etc).
+]]
+[[`BOOST_STATIC_CONSTANT(Type, assignment)`][
+On compilers which don't allow in-class initialization of static integral
+constant members, we must use enums as a workaround if we want the constants
+to be available at compile-time. This macro gives us a convenient way to
+declare such constants.
+For example instead of:
+``
+struct foo{
+ static const int value = 2;
+};
+``
+use:
+``
+struct foo{
+ BOOST_STATIC_CONSTANT(int, value = 2);
+};
+``
+]]
+[[`BOOST_UNREACHABLE_RETURN(result)`][
+Normally evaluates to nothing, but evaluates to return x; if the compiler
+requires a return, even when it can never be reached.
+]]
+[[`BOOST_EXPLICIT_TEMPLATE_TYPE(t)`
+ `BOOST_EXPLICIT_TEMPLATE_NON_TYPE(t,v)`
+ `BOOST_APPEND_EXPLICIT_TEMPLATE_TYPE(t)`
+ `BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(t,v)`][
+Some compilers silently "fold" different function template instantiations if
+some of the template parameters don't appear in the function parameter list.
+For instance:
+``
+ #include
+ #include
+ #include
+
+ template
+ void f() { std::cout << n << ' '; }
+
+ template
+ void g() { std::cout << typeid(T).name() << ' '; }
+
+ int main() {
+ f<1>();
+ f<2>();
+
+ g();
+ g();
+ }
+``
+incorrectly outputs [^2 2 double double] on VC++ 6. These macros, to be used
+in the function parameter list, fix the problem without effects on the calling
+syntax. For instance, in the case above write:
+``
+ template
+ void f(BOOST_EXPLICIT_TEMPLATE_NON_TYPE(int, n)) { ... }
+
+ template
+ void g(BOOST_EXPLICIT_TEMPLATE_TYPE(T)) { ... }
+``
+Beware that they can declare (for affected compilers) a dummy defaulted
+parameter, so they
+
+[*a)] should be always invoked [*at the end] of the parameter list
+
+[*b)] can't be used if your function template is multiply declared.
+
+Furthermore, in order to add any needed comma separator, an `APPEND_*` version
+must be used when the macro invocation appears after a normal parameter
+declaration or after the invocation of another macro of this same group.
+]]
+[[`BOOST_USE_FACET(Type, loc)`][
+When the standard library does not have a comforming `std::use_facet` there
+are various workarounds available, but they differ from library to library.
+This macro provides a consistent way to access a locale's facets. For example,
+replace:
+`std::use_facet(loc);`
+with:
+`BOOST_USE_FACET(Type, loc);`
+Note do not add a `std::` prefix to the front of `BOOST_USE_FACET`.
+]]
+[[`BOOST_HAS_FACET(Type, loc)`][
+When the standard library does not have a comforming `std::has_facet` there
+are various workarounds available, but they differ from library to library.
+This macro provides a consistent way to check a locale's facets. For example,
+replace:
+`std::has_facet(loc);`
+with:
+`BOOST_HAS_FACET(Type, loc);`
+Note do not add a `std::` prefix to the front of `BOOST_HAS_FACET`.
+]]
+[[`BOOST_NESTED_TEMPLATE`][
+Member templates are supported by some compilers even though they can't use
+the `A::template member` syntax, as a workaround replace:
+`typedef typename A::template rebind binder;`
+with:
+`typedef typename A::BOOST_NESTED_TEMPLATE rebind binder;`
+]]
+[[`BOOST_STRINGIZE(X)`][
+Converts the parameter `X` to a string after macro replacement on `X` has
+been performed.
+]]
+[[`BOOST_JOIN(X,Y)`][
+This piece of macro magic joins the two arguments together, even when one of
+the arguments is itself a macro (see 16.3.1 in C++ standard). This is normally
+used to create a mangled name in combination with a predefined macro such a
+\_\_LINE__.
+]]
+]
+
+[endsect]
+
+[#config_info_macros]
+
+[section Boost Informational Macros]
+
+The following macros describe boost features; these are, generally speaking
+the only boost macros that should be tested in user code.
+
+[table
+
+[[Macro ][Header ][Description ]]
+
+[[`BOOST_VERSION`][``][
+Describes the boost version number in XXYYZZ format such that:
+`(BOOST_VERSION % 100)` is the sub-minor version, `((BOOST_VERSION / 100) % 1000)`
+is the minor version, and `(BOOST_VERSION / 100000)` is the major version.
+]]
+[[`BOOST_NO_INT64_T`][`` ``][
+Defined if there are no 64-bit integral types: `int64_t`, `uint64_t` etc.
+]]
+[[`BOOST_NO_INTEGRAL_INT64_T`][`` ``][
+Defined if `int64_t` as defined by `` is not usable in
+integral constant expressions.
+]]
+[[`BOOST_MSVC`][``][
+Defined if the compiler is really Microsoft Visual C++, as opposed to one
+of the many other compilers that also define `_MSC_VER`.
+]]
+[[`BOOST_INTEL`][``][
+Defined if the compiler is an Intel compiler, takes the same value as the
+compiler version macro.
+]]
+[[`BOOST_WINDOWS`][``][
+Defined if the Windows platfrom API is available.
+]]
+[[`BOOST_DINKUMWARE_STDLIB`][``][
+Defined if the dinkumware standard library is in use, takes the same value
+as the Dinkumware library version macro `_CPPLIB_VER` if defined, otherwise 1.
+]]
+[[`BOOST_NO_WREGEX`][``][
+Defined if the regex library does not support wide character regular
+expressions.
+]]
+[[`BOOST_COMPILER`][``][
+Defined as a string describing the name and version number of the compiler
+in use. Mainly for debugging the configuration.
+]]
+[[`BOOST_STDLIB`][``][
+Defined as a string describing the name and version number of the standard
+library in use. Mainly for debugging the configuration.
+]]
+[[`BOOST_PLATFORM`][``][
+Defined as a string describing the name of the platform. Mainly for debugging
+the configuration.
+]]
+]
+
+[endsect]
+
+[section Macros for libraries with separate source code]
+
+The following macros and helper headers are of use to authors whose libraries
+include separate source code, and are intended to address two issues: fixing
+the ABI of the compiled library, and selecting which compiled library to link
+against based upon the compilers settings.
+
+[section ABI Fixing]
+
+When linking against a pre-compiled library it vital that the ABI used by the
+compiler when building the library ['matches exactly] the ABI used by the code
+using the library. In this case ABI means things like the struct packing
+arrangement used, the name mangling scheme used, or the size of some types
+(enum types for example). This is separate from things like threading support,
+or runtime library variations, which have to be dealt with by build variants.
+To put this in perspective there is one compiler (Borland's) that has so many
+compiler options that make subtle changes to the ABI, that at least in theory
+there 3200 combinations, and that's without considering runtime library
+variations. Fortunately these variations can be managed by `#pragma`'s that
+tell the compiler what ABI to use for the types declared in your library.
+In order to avoid sprinkling `#pragma`'s all over the boost headers, there are
+some prefix and suffix headers that do the job. Typical usage is:
+
+[*my_library.hpp]
+
+ #ifndef MY_INCLUDE_GUARD
+ #define MY_INCLUDE_GUARD
+
+ // all includes go here:
+ ``[^[*#include ]]``
+ #include
+
+ ``[^[*#include ]]`` // must be the last #include
+
+ namespace boost {
+
+ // your code goes here
+
+ }
+
+ ``[^[*#include ]]`` // pops abi_prefix.hpp pragmas
+
+ #endif // include guard
+
+[*my_library.cpp]
+
+ ...
+ // nothing special need be done in the implementation file
+ ...
+
+The user can disable this mechanism by defining `BOOST_DISABLE_ABI_HEADERS`, or
+they can define `BOOST_ABI_PREFIX` and/or `BOOST_ABI_SUFFIX` to point to their
+own prefix/suffix headers if they so wish.
+
+[endsect]
+
+[section Automatic library selection]
+
+It is essential that users link to a build of a library which was built against
+the same runtime library that their application will be built against -if this
+does not happen then the library will not be binary compatible with their own
+code- and there is a high likelihood that their application will experience
+runtime crashes. These kinds of problems can be extremely time consuming and
+difficult to debug, and often lead to frustrated users and authors alike (simply
+selecting the right library to link against is not as easy as it seems when
+their are 6-8 of them to chose from, and some users seem to be blissfully
+unaware that there even are different runtimes available to them).
+
+To solve this issue, some compilers allow source code to contain `#pragma`'s that
+instruct the linker which library to link against, all the user need do is
+include the headers they need, place the compiled libraries in their library
+search path, and the compiler and linker do the rest. Boost.config supports
+this via the header ``, before including this header
+one or more of the following macros need to be defined:
+
+[variablelist
+[[`BOOST_LIB_NAME`][
+Required: An identifier containing the basename of the library, for
+example 'boost_regex'.
+]]
+[[`BOOST_DYN_LINK`][
+Optional: when set link to dll rather than static library.
+]]
+[[`BOOST_LIB_DIAGNOSTIC`][
+Optional: when set the header will print out the name of the library selected
+(useful for debugging).
+]]
+]
+
+If the compiler supports this mechanism, then it will be told to link against
+the appropriately named library, the actual algorithm used to mangle the name
+of the library is documented inside `` and has to
+match that used to create the libraries via bjam 's install rules.
+
+
+[*my_library.hpp]
+
+ ...
+ //
+ // Don't include auto-linking code if the user has disabled it by
+ // defining BOOST_ALL_NO_LIB, or BOOST_MY_LIBRARY_NO_LIB, or if this
+ // is one of our own source files (signified by BOOST_MY_LIBRARY_SOURCE):
+ //
+ #if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_MY_LIBRARY_NO_LIB) && !defined(BOOST_MY_LIBRARY_SOURCE)
+ # define BOOST_LIB_NAME boost_my_library
+ # ifdef BOOST_MY_LIBRARY_DYN_LINK
+ # define BOOST_DYN_LINK
+ # endif
+ # include
+ #endif
+ ...
+
+[*my_library.cpp]
+
+ // define BOOST_MY_LIBRARY_SOURCE so that the header knows that the
+ // library is being built (possibly exporting rather than importing code)
+ //
+ #define BOOST_MY_LIBRARY_SOURCE
+
+ #include
+ ...
+
+[endsect]
+
+[endsect]
+
+[endsect]
diff --git a/doc/rationale.qbk b/doc/rationale.qbk
new file mode 100644
index 00000000..7ca27a47
--- /dev/null
+++ b/doc/rationale.qbk
@@ -0,0 +1,82 @@
+[/
+ Boost.Config
+
+ Copyright (c) 2001 Beman Dawes
+ Copyright (c) 2001 Vesa Karvonen
+ Copyright (c) 2001 John Maddock
+
+ Distributed under the Boost Software License, Version 1.0.
+ (See accompanying file LICENSE_1_0.txt or copy at
+ http://www.boost.org/LICENSE_1_0.txt)
+]
+
+[#config_rationale]
+
+[section Rationale]
+
+The problem with many traditional "textbook" implementations of configuration
+headers (where all the configuration options are in a single "monolithic"
+header) is that they violate certain fundamental software engineering
+principles which would have the effect of making boost more fragile, more
+difficult to maintain and more difficult to use safely. You can find a
+description of the principles from the __PRINCIPLES_AND_PATTERNS_ARTICLE__.
+
+[section The problem]
+
+Consider a situation in which you are concurrently developing on multiple
+platforms. Then consider adding a new platform or changing the platform
+definitions of an existing platform. What happens? Everything, and this does
+literally mean everything, recompiles. Isn't it quite absurd that adding a
+new platform, which has absolutely nothing to do with previously existing
+platforms, means that all code on all existing platforms needs to be
+recompiled?
+
+Effectively, there is an imposed physical dependency between platforms that
+have nothing to do with each other. Essentially, the traditional solution
+employed by configuration headers does not conform to the Open-Closed
+Principle:
+
+[: [*"A module should be open for extension but closed for modification."]]
+
+Extending a traditional configuration header implies modifying existing code.
+
+Furthermore, consider the complexity and fragility of the platform detection
+code. What if a simple change breaks the detection on some minor platform?
+What if someone accidentally or on purpose (as a workaround for some other
+problem) defines some platform dependent macros that are used by the
+detection code? A traditional configuration header is one of the most
+volatile headers of the entire library, and more stable elements of
+Boost would depend on it. This violates the Stable Dependencies Principle:
+
+[: [*"Depend in the direction of stability."]]
+
+After even a minor change to a traditional configuration header on one minor
+platform, almost everything on every platform should be tested if we follow
+sound software engineering practice.
+
+Another important issue is that it is not always possible to submit changes
+to ``. Some boost users are currently working on platforms
+using tools and libraries that are under strict Non-Disclosure Agreements.
+In this situation it is impossible to submit changes to a traditional
+monolithic configuration header, instead some method by which the user
+can insert their own configuration code must be provided.
+
+[endsect]
+
+[section The solution]
+
+The approach taken by boost's configuration headers is to separate
+configuration into three orthogonal parts: the compiler, the standard
+library and the platform. Each compiler/standard library/platform gets
+its own mini-configuration header, so that changes to one compiler's
+configuration (for example) does not affect other compilers. In addition
+there are measures that can be taken both to omit the compiler/standard
+library/platform detection code (so that adding support to a new platform
+does not break dependencies), or to freeze the configuration completely;
+providing almost complete protection against dependency changes.
+
+[endsect]
+
+[endsect]
+
+
diff --git a/include/boost/config/abi_prefix.hpp b/include/boost/config/abi_prefix.hpp
index 1733dc03..a785cff0 100644
--- a/include/boost/config/abi_prefix.hpp
+++ b/include/boost/config/abi_prefix.hpp
@@ -18,3 +18,8 @@
#ifdef BOOST_HAS_ABI_HEADERS
# include BOOST_ABI_PREFIX
#endif
+
+#if defined( __BORLANDC__ )
+#pragma nopushoptwarn
+#endif
+
diff --git a/include/boost/config/abi_suffix.hpp b/include/boost/config/abi_suffix.hpp
index 6339da63..d49417a9 100644
--- a/include/boost/config/abi_suffix.hpp
+++ b/include/boost/config/abi_suffix.hpp
@@ -20,4 +20,7 @@
# include BOOST_ABI_SUFFIX
#endif
+#if defined( __BORLANDC__ )
+#pragma nopushoptwarn
+#endif
diff --git a/include/boost/config/auto_link.hpp b/include/boost/config/auto_link.hpp
index f4910427..df58d4f9 100644
--- a/include/boost/config/auto_link.hpp
+++ b/include/boost/config/auto_link.hpp
@@ -130,11 +130,16 @@ BOOST_LIB_VERSION: The Boost version, in the form x_y, for Boost version x.y.
// vc71:
# define BOOST_LIB_TOOLSET "vc71"
-#elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1400)
+#elif defined(BOOST_MSVC) && (BOOST_MSVC == 1400)
// vc80:
# define BOOST_LIB_TOOLSET "vc80"
+#elif defined(BOOST_MSVC) && (BOOST_MSVC >= 1500)
+
+ // vc90:
+# define BOOST_LIB_TOOLSET "vc90"
+
#elif defined(__BORLANDC__)
// CBuilder 6:
diff --git a/include/boost/config/compiler/borland.hpp b/include/boost/config/compiler/borland.hpp
index b0d6ab0b..3be33927 100644
--- a/include/boost/config/compiler/borland.hpp
+++ b/include/boost/config/compiler/borland.hpp
@@ -14,13 +14,11 @@
// we don't support Borland prior to version 5.4:
#if __BORLANDC__ < 0x540
# error "Compiler not supported or configured - please reconfigure"
-#elif __BORLANDC__ < 0x581
-# pragma message( "Support for Borland compilers older than BCB2006 is deprecated in Boost 1.34" )
#endif
// last known and checked version is 0x600 (Builder X preview)
-// Or 0x582 (Borland C++ Builder 2006 Update 1):
-#if (__BORLANDC__ > 0x582) && (__BORLANDC__ != 0x600)
+// or 0x592 (CodeGear C++ Builder 2007 Update 3):
+#if (__BORLANDC__ > 0x592) && (__BORLANDC__ != 0x600)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
@@ -38,7 +36,6 @@
# define BOOST_BCB_WITH_DINKUMWARE
#endif
-
//
// Version 5.0 and below:
# if __BORLANDC__ <= 0x0550
@@ -54,7 +51,6 @@
#if (__BORLANDC__ <= 0x551)
# define BOOST_NO_CV_SPECIALIZATIONS
# define BOOST_NO_CV_VOID_SPECIALIZATIONS
-# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
# define BOOST_NO_DEDUCED_TYPENAME
// workaround for missing WCHAR_MAX/WCHAR_MIN:
#include
@@ -67,22 +63,9 @@
#endif
#endif
-// Borland C++ Builder 2006 Update 2 and below:
-#if (__BORLANDC__ <= 0x582)
-# define BOOST_NO_SFINAE
+// Borland C++ Builder 6 and below:
+#if (__BORLANDC__ <= 0x564)
# define BOOST_NO_INTEGRAL_INT64_T
-# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
-# define BOOST_NO_PRIVATE_IN_AGGREGATE
-# define BOOST_NO_USING_TEMPLATE
-# define BOOST_BCB_PARTIAL_SPECIALIZATION_BUG
-# define BOOST_NO_TEMPLATE_TEMPLATES
-# define BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
-# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
- // we shouldn't really need this - but too many things choke
- // without it, this needs more investigation:
-# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
-# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
-# define BOOST_NO_IS_ABSTRACT
# ifdef NDEBUG
// fix broken so that Boost.test works:
@@ -95,6 +78,8 @@
# define errno errno
# endif
+#endif
+
//
// new bug in 5.61:
#if (__BORLANDC__ >= 0x561) && (__BORLANDC__ <= 0x580)
@@ -102,6 +87,14 @@
# define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS
#endif
+// Borland C++ Builder 2006 Update 2 and below:
+#if (__BORLANDC__ <= 0x582)
+# define BOOST_NO_SFINAE
+# define BOOST_BCB_PARTIAL_SPECIALIZATION_BUG
+# define BOOST_NO_TEMPLATE_TEMPLATES
+
+# define BOOST_NO_PRIVATE_IN_AGGREGATE
+
# ifdef _WIN32
# define BOOST_NO_SWPRINTF
# elif defined(linux) || defined(__linux__) || defined(__linux)
@@ -113,6 +106,31 @@
# endif
#endif
+// Borland C++ Builder 2007 Update 3 and below:
+#if (__BORLANDC__ <= 0x592)
+# define BOOST_NO_DEPENDENT_NESTED_DERIVATIONS
+# define BOOST_NO_USING_TEMPLATE
+# define BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
+ // we shouldn't really need this - but too many things choke
+ // without it, this needs more investigation:
+# define BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS
+# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
+# define BOOST_NO_IS_ABSTRACT
+# define BOOST_NO_FUNCTION_TYPE_SPECIALIZATIONS
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+
+// Temporary workaround
+#define BOOST_MPL_CFG_NO_PREPROCESSED_HEADERS
+
+#endif
+
+#if __BORLANDC__ >= 0x590
+# define BOOST_HAS_TR1_HASH
+
+# define BOOST_HAS_MACRO_USE_FACET
+#endif
+
//
// Post 0x561 we have long long and stdint.h:
#if __BORLANDC__ >= 0x561
@@ -188,3 +206,4 @@
#define BOOST_COMPILER "Borland C++ version " BOOST_STRINGIZE(__BORLANDC__)
+
diff --git a/include/boost/config/compiler/compaq_cxx.hpp b/include/boost/config/compiler/compaq_cxx.hpp
index a52e66a2..b44486c6 100644
--- a/include/boost/config/compiler/compaq_cxx.hpp
+++ b/include/boost/config/compiler/compaq_cxx.hpp
@@ -5,9 +5,9 @@
// See http://www.boost.org for most recent version.
-// Dec Alpha True64 C++ compiler setup:
+// Tru64 C++ compiler setup (now HP):
-#define BOOST_COMPILER "Dec Alpha True64 " BOOST_STRINGIZE(__DECCXX_VER)
+#define BOOST_COMPILER "HP Tru64 C++ " BOOST_STRINGIZE(__DECCXX_VER)
#include "boost/config/compiler/common_edg.hpp"
diff --git a/include/boost/config/compiler/digitalmars.hpp b/include/boost/config/compiler/digitalmars.hpp
index 32fc71fa..46848479 100644
--- a/include/boost/config/compiler/digitalmars.hpp
+++ b/include/boost/config/compiler/digitalmars.hpp
@@ -36,13 +36,31 @@
#define BOOST_HAS_WINTHREADS
#endif
+#if (__DMC__ >= 0x847)
+#define BOOST_HAS_EXPM1
+#define BOOST_HAS_LOG1P
+#endif
+
+//
+// Is this really the best way to detect whether the std lib is in namespace std?
+//
+#include
+#if !defined(__STL_IMPORT_VENDOR_CSTD) && !defined(_STLP_IMPORT_VENDOR_CSTD)
+# define BOOST_NO_STDC_NAMESPACE
+#endif
+
// check for exception handling support:
#ifndef _CPPUNWIND
# define BOOST_NO_EXCEPTIONS
#endif
-#if (__DMC__ < 0x840)
+#if __DMC__ < 0x800
+#error "Compiler not supported or configured - please reconfigure"
+#endif
+//
+// last known and checked version is ...:
+#if (__DMC__ > 0x848)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
diff --git a/include/boost/config/compiler/gcc.hpp b/include/boost/config/compiler/gcc.hpp
index d94b16b7..17895dcb 100644
--- a/include/boost/config/compiler/gcc.hpp
+++ b/include/boost/config/compiler/gcc.hpp
@@ -43,6 +43,10 @@
# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
# define BOOST_NO_IS_ABSTRACT
#elif __GNUC__ == 3
+# if defined (__PATHSCALE__)
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+# define BOOST_NO_IS_ABSTRACT
+# endif
//
// gcc-3.x problems:
//
@@ -55,6 +59,12 @@
# define BOOST_NO_IS_ABSTRACT
# endif
#endif
+#if __GNUC__ < 4
+//
+// All problems to gcc-3.x and earlier here:
+//
+#define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#endif
#ifndef __EXCEPTIONS
# define BOOST_NO_EXCEPTIONS
@@ -82,7 +92,41 @@
#define BOOST_HAS_NRVO
#endif
-#define BOOST_COMPILER "GNU C++ version " __VERSION__
+//
+// C++0x features
+//
+#if __GNUC__ > 4 || (__GNUC__ == 4 && __GNUC_MINOR__ > 2)
+// C++0x features are only enabled when -std=c++0x or -std=gnu++0x are
+// passed on the command line, which in turn defines
+// __GXX_EXPERIMENTAL_CXX0X__.
+# if defined(__GXX_EXPERIMENTAL_CXX0X__)
+# define BOOST_HAS_STATIC_ASSERT
+# define BOOST_HAS_VARIADIC_TMPL
+# define BOOST_HAS_RVALUE_REFS
+# define BOOST_HAS_DECLTYPE
+# endif
+#endif
+
+//
+// Potential C++0x features
+//
+
+// Variadic templates compiler:
+// http://www.generic-programming.org/~dgregor/cpp/variadic-templates.html
+#ifdef __VARIADIC_TEMPLATES
+# define BOOST_HAS_VARIADIC_TMPL
+#endif
+
+// ConceptGCC compiler:
+// http://www.generic-programming.org/software/ConceptGCC/
+#ifdef __GXX_CONCEPTS__
+# define BOOST_HAS_CONCEPTS
+# define BOOST_COMPILER "ConceptGCC version " __VERSION__
+#endif
+
+#ifndef BOOST_COMPILER
+# define BOOST_COMPILER "GNU C++ version " __VERSION__
+#endif
//
// versions check:
@@ -91,8 +135,8 @@
# error "Compiler not configured - please reconfigure"
#endif
//
-// last known and checked version is 4.0 (Pre-release):
-#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ > 0))
+// last known and checked version is 4.3 (Pre-release):
+#if (__GNUC__ > 4) || ((__GNUC__ == 4) && (__GNUC_MINOR__ > 3))
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
diff --git a/include/boost/config/compiler/hp_acc.hpp b/include/boost/config/compiler/hp_acc.hpp
index 79405fc4..5a766c59 100644
--- a/include/boost/config/compiler/hp_acc.hpp
+++ b/include/boost/config/compiler/hp_acc.hpp
@@ -1,11 +1,9 @@
// (C) Copyright John Maddock 2001 - 2003.
// (C) Copyright Jens Maurer 2001 - 2003.
-// (C) Copyright John Maddock 2001 - 2003.
-// (C) Copyright Jens Maurer 2001 - 2003.
// (C) Copyright Aleksey Gurtovoy 2002.
// (C) Copyright David Abrahams 2002 - 2003.
// (C) Copyright Toon Knapen 2003.
-// (C) Copyright Boris Gubenko 2006.
+// (C) Copyright Boris Gubenko 2006 - 2007.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
@@ -14,7 +12,7 @@
// HP aCC C++ compiler setup:
-#if (__HP_aCC >= 61200) && defined(__EDG__)
+#if defined(__EDG__)
#include "boost/config/compiler/common_edg.hpp"
#endif
@@ -34,7 +32,11 @@
# define BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
#endif
-#if (__HP_aCC < 60000)
+#if (__HP_aCC <= 38000)
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#endif
+
+#if (__HP_aCC > 50000) && (__HP_aCC < 60000)
# define BOOST_NO_UNREACHABLE_RETURN_DETECTION
# define BOOST_NO_TEMPLATE_TEMPLATES
# define BOOST_NO_SWPRINTF
@@ -53,6 +55,15 @@
# define BOOST_NO_MEMBER_TEMPLATE_KEYWORD
#endif
+// This macro should not be defined when compiling in strict ansi
+// mode, but, currently, we don't have the ability to determine
+// what standard mode we are compiling with. Some future version
+// of aCC6 compiler will provide predefined macros reflecting the
+// compilation options, including the standard mode.
+#if (__HP_aCC >= 60000) || ((__HP_aCC > 38000) && defined(__hpxstd98))
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#endif
+
#define BOOST_COMPILER "HP aCC version " BOOST_STRINGIZE(__HP_aCC)
//
@@ -61,12 +72,24 @@
#if __HP_aCC < 33000
# error "Compiler not supported or configured - please reconfigure"
#endif
+
//
-// last known and checked version is 61300:
-#if (__HP_aCC > 61300)
+// Extended checks for supporting aCC on PA-RISC
+#if __HP_aCC > 30000 && __HP_aCC < 50000
+# if __HP_aCC < 38000
+ // versions prior to version A.03.80 not supported
+# error "Compiler version not supported - version A.03.80 or higher is required"
+# elif !defined(__hpxstd98)
+ // must compile using the option +hpxstd98 with version A.03.80 and above
+# error "Compiler option '+hpxstd98' is required for proper support"
+# endif //PA-RISC
+#endif
+
+//
+// last known and checked version for HP-UX/ia64 is 61300
+// last known and checked version for PA-RISC is 38000
+#if ((__HP_aCC > 61300) || ((__HP_aCC > 38000) && defined(__hpxstd98)))
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# endif
#endif
-
-
diff --git a/include/boost/config/compiler/intel.hpp b/include/boost/config/compiler/intel.hpp
index 87920e49..0cd678a0 100644
--- a/include/boost/config/compiler/intel.hpp
+++ b/include/boost/config/compiler/intel.hpp
@@ -1,4 +1,4 @@
-// (C) Copyright John Maddock 2001.
+// (C) Copyright John Maddock 2001-7.
// (C) Copyright Peter Dimov 2001.
// (C) Copyright Jens Maurer 2001.
// (C) Copyright David Abrahams 2002 - 2003.
@@ -99,7 +99,10 @@
# define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
# endif
#endif
-
+#if (defined(__GNUC__) && (__GNUC__ < 4)) || defined(_WIN32)
+// GCC or VC emulation:
+#define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#endif
//
// Verify that we have actually got BOOST_NO_INTRINSIC_WCHAR_T
// set correctly, if we don't do this now, we will get errors later
@@ -125,6 +128,7 @@ template<> struct assert_intrinsic_wchar_t {};
# define BOOST_HAS_MS_INT64
# endif
# define BOOST_NO_SWPRINTF
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
#elif defined(_WIN32)
# define BOOST_DISABLE_WIN32
#endif
@@ -144,7 +148,7 @@ template<> struct assert_intrinsic_wchar_t {};
#endif
//
// last known and checked version:
-#if (BOOST_INTEL_CXX_VERSION > 910)
+#if (BOOST_INTEL_CXX_VERSION > 1000)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# elif defined(_MSC_VER)
@@ -156,3 +160,4 @@ template<> struct assert_intrinsic_wchar_t {};
+
diff --git a/include/boost/config/compiler/metrowerks.hpp b/include/boost/config/compiler/metrowerks.hpp
index f173295e..2b60b56f 100644
--- a/include/boost/config/compiler/metrowerks.hpp
+++ b/include/boost/config/compiler/metrowerks.hpp
@@ -80,6 +80,13 @@
# define BOOST_COMPILER_VERSION __MWERKS__
#endif
+//
+// C++0x features
+//
+#if __MWERKS__ > 0x3206 && __option(rvalue_refs)
+# define BOOST_HAS_RVALUE_REFS
+#endif
+
#define BOOST_COMPILER "Metrowerks CodeWarrior C++ version " BOOST_STRINGIZE(BOOST_COMPILER_VERSION)
//
diff --git a/include/boost/config/compiler/pgi.hpp b/include/boost/config/compiler/pgi.hpp
new file mode 100644
index 00000000..491497d4
--- /dev/null
+++ b/include/boost/config/compiler/pgi.hpp
@@ -0,0 +1,25 @@
+// (C) Copyright Noel Belcourt 2007.
+// Use, modification and distribution are subject to the
+// Boost Software License, Version 1.0. (See accompanying file
+// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+
+// See http://www.boost.org for most recent version.
+
+// PGI C++ compiler setup:
+
+#define BOOST_COMPILER "PGI compiler version " BOOST_STRINGIZE(_COMPILER_VERSION)
+
+//
+// Threading support:
+// Turn this on unconditionally here, it will get turned off again later
+// if no threading API is detected.
+//
+
+#define BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL
+#define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#define BOOST_NO_SWPRINTF
+
+//
+// version check:
+// probably nothing to do here?
+
diff --git a/include/boost/config/compiler/sgi_mipspro.hpp b/include/boost/config/compiler/sgi_mipspro.hpp
index 689b67ee..33e97e9a 100644
--- a/include/boost/config/compiler/sgi_mipspro.hpp
+++ b/include/boost/config/compiler/sgi_mipspro.hpp
@@ -17,6 +17,10 @@
// if no threading API is detected.
//
#define BOOST_HAS_THREADS
+#define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+
+#undef BOOST_NO_SWPRINTF
+#undef BOOST_DEDUCED_TYPENAME
//
// version check:
// probably nothing to do here?
diff --git a/include/boost/config/compiler/sunpro_cc.hpp b/include/boost/config/compiler/sunpro_cc.hpp
index b256d843..afa04ce1 100644
--- a/include/boost/config/compiler/sunpro_cc.hpp
+++ b/include/boost/config/compiler/sunpro_cc.hpp
@@ -69,6 +69,12 @@
# define BOOST_NO_IS_ABSTRACT
# endif
+//
+// Issues that effect all known versions:
+//
+#define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+
+
#define BOOST_COMPILER "Sun compiler version " BOOST_STRINGIZE(__SUNPRO_CC)
//
diff --git a/include/boost/config/compiler/vacpp.hpp b/include/boost/config/compiler/vacpp.hpp
index e085a60d..b930dafd 100644
--- a/include/boost/config/compiler/vacpp.hpp
+++ b/include/boost/config/compiler/vacpp.hpp
@@ -52,6 +52,9 @@
# endif
#endif
+// Some versions of the compiler have issues with default arguments on partial specializations
+#define BOOST_PARTIAL_SPECIALIZATION_EXPLICT_ARGS
+
diff --git a/include/boost/config/compiler/visualc.hpp b/include/boost/config/compiler/visualc.hpp
index 2885a418..233fdb9f 100644
--- a/include/boost/config/compiler/visualc.hpp
+++ b/include/boost/config/compiler/visualc.hpp
@@ -56,6 +56,7 @@
# define BOOST_NO_SFINAE
# define BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS
# define BOOST_NO_IS_ABSTRACT
+# define BOOST_NO_FUNCTION_TYPE_SPECIALIZATIONS
// TODO: what version is meant here? Have there really been any fixes in cl 12.01 (as e.g. shipped with eVC4)?
# if (_MSC_VER > 1200)
# define BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS
@@ -73,6 +74,10 @@
# define BOOST_NO_MEMBER_TEMPLATE_FRIENDS
#endif
+#if _MSC_VER <= 1500 // 1500 == VC++ 9.0
+# define BOOST_NO_TWO_PHASE_NAME_LOOKUP
+#endif
+
#ifndef _NATIVE_WCHAR_T_DEFINED
# define BOOST_NO_INTRINSIC_WCHAR_T
#endif
@@ -154,6 +159,8 @@
# define BOOST_COMPILER_VERSION 7.1
# elif _MSC_VER == 1400
# define BOOST_COMPILER_VERSION 8.0
+# elif _MSC_VER == 1500
+# define BOOST_COMPILER_VERSION 9.0
# else
# define BOOST_COMPILER_VERSION _MSC_VER
# endif
@@ -169,7 +176,7 @@
#endif
//
// last known and checked version is 1400 (VC8):
-#if (_MSC_VER > 1400)
+#if (_MSC_VER > 1500)
# if defined(BOOST_ASSERT_CONFIG)
# error "Unknown compiler version - please run the configure tests and report the results"
# else
diff --git a/include/boost/config/platform/cygwin.hpp b/include/boost/config/platform/cygwin.hpp
index 0fd2ebe2..41fcaa10 100644
--- a/include/boost/config/platform/cygwin.hpp
+++ b/include/boost/config/platform/cygwin.hpp
@@ -12,6 +12,8 @@
#define BOOST_NO_CWCHAR
#define BOOST_NO_SWPRINTF
#define BOOST_HAS_DIRENT_H
+#define BOOST_HAS_LOG1P
+#define BOOST_HAS_EXPM1
//
// Threading API:
@@ -46,3 +48,4 @@
+
diff --git a/include/boost/config/platform/hpux.hpp b/include/boost/config/platform/hpux.hpp
index 57566b70..25cd8ebc 100644
--- a/include/boost/config/platform/hpux.hpp
+++ b/include/boost/config/platform/hpux.hpp
@@ -2,7 +2,7 @@
// (C) Copyright Jens Maurer 2001 - 2003.
// (C) Copyright David Abrahams 2002.
// (C) Copyright Toon Knapen 2003.
-// (C) Copyright Boris Gubenko 2006.
+// (C) Copyright Boris Gubenko 2006 - 2007.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
@@ -72,7 +72,9 @@
# define BOOST_HAS_SIGACTION
#endif
#ifndef BOOST_HAS_NRVO
-# define BOOST_HAS_NRVO
+# ifndef __parisc
+# define BOOST_HAS_NRVO
+# endif
#endif
#ifndef BOOST_HAS_LOG1P
# define BOOST_HAS_LOG1P
@@ -80,6 +82,3 @@
#ifndef BOOST_HAS_EXPM1
# define BOOST_HAS_EXPM1
#endif
-
-
-
diff --git a/include/boost/config/select_compiler_config.hpp b/include/boost/config/select_compiler_config.hpp
index 3c960b3b..8d8db903 100644
--- a/include/boost/config/select_compiler_config.hpp
+++ b/include/boost/config/select_compiler_config.hpp
@@ -2,12 +2,36 @@
// (C) Copyright John Maddock 2001 - 2003.
// (C) Copyright Martin Wille 2003.
-// (C) Copyright Guillaume Melquiond 2003.
-// Use, modification and distribution are subject to the
-// Boost Software License, Version 1.0. (See accompanying file
-// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
+// (C) Copyright Guillaume Melquiond 2003.
+//
+// Distributed under the Boost Software License, Version 1.0.
+// (See accompanying file LICENSE_1_0.txt or copy at
+// http://www.boost.org/LICENSE_1_0.txt)
+
+// See http://www.boost.org/ for most recent version.
+
+
+// one identification macro for each of the
+// compilers we support:
+
+# define BOOST_CXX_GCCXML 0
+# define BOOST_CXX_COMO 0
+# define BOOST_CXX_DMC 0
+# define BOOST_CXX_INTEL 0
+# define BOOST_CXX_GNUC 0
+# define BOOST_CXX_KCC 0
+# define BOOST_CXX_SGI 0
+# define BOOST_CXX_TRU64 0
+# define BOOST_CXX_GHS 0
+# define BOOST_CXX_BORLAND 0
+# define BOOST_CXX_CW 0
+# define BOOST_CXX_SUNPRO 0
+# define BOOST_CXX_HPACC 0
+# define BOOST_CXX_MPW 0
+# define BOOST_CXX_IBMCPP 0
+# define BOOST_CXX_MSVC 0
+# define BOOST_CXX_PGI 0
-// See http://www.boost.org for most recent version.
// locate which compiler we are using and define
// BOOST_COMPILER_CONFIG as needed:
@@ -72,6 +96,10 @@
// IBM Visual Age
# define BOOST_COMPILER_CONFIG "boost/config/compiler/vacpp.hpp"
+#elif defined(__PGI)
+// Portland Group Inc.
+# define BOOST_COMPILER_CONFIG "boost/config/compiler/pgi.hpp"
+
#elif defined _MSC_VER
// Microsoft Visual C++
//
diff --git a/include/boost/config/stdlib/roguewave.hpp b/include/boost/config/stdlib/roguewave.hpp
index 49d0106d..ebf4c1f8 100644
--- a/include/boost/config/stdlib/roguewave.hpp
+++ b/include/boost/config/stdlib/roguewave.hpp
@@ -1,6 +1,7 @@
// (C) Copyright John Maddock 2001 - 2003.
// (C) Copyright Jens Maurer 2001.
// (C) Copyright David Abrahams 2003.
+// (C) Copyright Boris Gubenko 2007.
// Use, modification and distribution are subject to the
// Boost Software License, Version 1.0. (See accompanying file
// LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt)
@@ -28,8 +29,14 @@
#ifndef _RWSTD_VER
# define BOOST_STDLIB "Rogue Wave standard library version (Unknown version)"
+#elif _RWSTD_VER < 0x04010200
+ # define BOOST_STDLIB "Rogue Wave standard library version " BOOST_STRINGIZE(_RWSTD_VER)
#else
-# define BOOST_STDLIB "Rogue Wave standard library version " BOOST_STRINGIZE(_RWSTD_VER)
+# ifdef _RWSTD_VER_STR
+# define BOOST_STDLIB "Apache STDCXX standard library version " _RWSTD_VER_STR
+# else
+# define BOOST_STDLIB "Apache STDCXX standard library version " BOOST_STRINGIZE(_RWSTD_VER)
+# endif
#endif
//
@@ -125,3 +132,22 @@
#if !defined(_RWSTD_LONG_LONG) && defined(BOOST_HAS_LONG_LONG)
# undef BOOST_HAS_LONG_LONG
#endif
+
+//
+// check that on HP-UX, the proper RW library is used
+//
+#if defined(__HP_aCC) && !defined(_HP_NAMESPACE_STD)
+# error "Boost requires Standard RW library. Please compile and link with -AA"
+#endif
+
+//
+// Define macros specific to RW V2.2 on HP-UX
+//
+#if defined(__HP_aCC) && (BOOST_RWSTD_VER == 0x02020100)
+# ifndef __HP_TC1_MAKE_PAIR
+# define __HP_TC1_MAKE_PAIR
+# endif
+# ifndef _HP_INSTANTIATE_STD2_VL
+# define _HP_INSTANTIATE_STD2_VL
+# endif
+#endif
diff --git a/include/boost/config/suffix.hpp b/include/boost/config/suffix.hpp
index 61a8d46a..b57d3f1e 100644
--- a/include/boost/config/suffix.hpp
+++ b/include/boost/config/suffix.hpp
@@ -45,7 +45,6 @@
# undef BOOST_NO_CTYPE_FUNCTIONS
#endif
-
//
// Assume any extensions are in namespace std:: unless stated otherwise:
//
@@ -565,5 +564,3 @@ namespace boost{
#endif
-
-
diff --git a/include/boost/detail/workaround.hpp b/include/boost/detail/workaround.hpp
index b10f9b58..4933a531 100644
--- a/include/boost/detail/workaround.hpp
+++ b/include/boost/detail/workaround.hpp
@@ -38,8 +38,136 @@
# ifndef BOOST_STRICT_CONFIG
+#include
+
+#ifndef __BORLANDC__
+#define __BORLANDC___WORKAROUND_GUARD 1
+#else
+#define __BORLANDC___WORKAROUND_GUARD 0
+#endif
+#ifndef __MSC_VER
+#define __MSC_VER_WORKAROUND_GUARD 1
+#else
+#define __MSC_VER_WORKAROUND_GUARD 0
+#endif
+#ifndef _MSC_FULL_VER
+#define _MSC_FULL_VER_WORKAROUND_GUARD 1
+#else
+#define _MSC_FULL_VER_WORKAROUND_GUARD 0
+#endif
+#ifndef BOOST_MSVC
+#define BOOST_MSVC_WORKAROUND_GUARD 1
+#else
+#define BOOST_MSVC_WORKAROUND_GUARD 0
+#endif
+#ifndef __GNUC__
+#define __GNUC___WORKAROUND_GUARD 1
+#else
+#define __GNUC___WORKAROUND_GUARD 0
+#endif
+#ifndef __GNUC_MINOR__
+#define __GNUC_MINOR___WORKAROUND_GUARD 1
+#else
+#define __GNUC_MINOR___WORKAROUND_GUARD 0
+#endif
+#ifndef __GNUC_PATCHLEVEL__
+#define __GNUC_PATCHLEVEL___WORKAROUND_GUARD 1
+#else
+#define __GNUC_PATCHLEVEL___WORKAROUND_GUARD 0
+#endif
+#ifndef __IBMCPP__
+#define __IBMCPP___WORKAROUND_GUARD 1
+#else
+#define __IBMCPP___WORKAROUND_GUARD 0
+#endif
+#ifndef __SUNPRO_CC
+#define __SUNPRO_CC_WORKAROUND_GUARD 1
+#else
+#define __SUNPRO_CC_WORKAROUND_GUARD 0
+#endif
+#ifndef __DECCXX_VER
+#define __DECCXX_VER_WORKAROUND_GUARD 1
+#else
+#define __DECCXX_VER_WORKAROUND_GUARD 0
+#endif
+#ifndef __MWERKS__
+#define __MWERKS___WORKAROUND_GUARD 1
+#else
+#define __MWERKS___WORKAROUND_GUARD 0
+#endif
+#ifndef __EDG_VERSION__
+#define __EDG_VERSION___WORKAROUND_GUARD 1
+#else
+#define __EDG_VERSION___WORKAROUND_GUARD 0
+#endif
+#ifndef __HP_aCC
+#define __HP_aCC_WORKAROUND_GUARD 1
+#else
+#define __HP_aCC_WORKAROUND_GUARD 0
+#endif
+#ifndef _CRAYC
+#define _CRAYC_WORKAROUND_GUARD 1
+#else
+#define _CRAYC_WORKAROUND_GUARD 0
+#endif
+#ifndef __DMC__
+#define __DMC___WORKAROUND_GUARD 1
+#else
+#define __DMC___WORKAROUND_GUARD 0
+#endif
+#ifndef MPW_CPLUS
+#define MPW_CPLUS_WORKAROUND_GUARD 1
+#else
+#define MPW_CPLUS_WORKAROUND_GUARD 0
+#endif
+
+#ifndef _RWSTD_VER
+#define _RWSTD_VER_WORKAROUND_GUARD 1
+#else
+#define _RWSTD_VER_WORKAROUND_GUARD 0
+#endif
+#ifndef _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC
+#define _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC_WORKAROUND_GUARD 1
+#else
+#define _GLIBCXX_USE_C99_FP_MACROS_DYNAMIC_WORKAROUND_GUARD 0
+#endif
+#ifndef __SGI_STL_PORT
+#define __SGI_STL_PORT_WORKAROUND_GUARD 1
+#else
+#define __SGI_STL_PORT_WORKAROUND_GUARD 0
+#endif
+#ifndef _STLPORT_VERSION
+#define _STLPORT_VERSION_WORKAROUND_GUARD 1
+#else
+#define _STLPORT_VERSION_WORKAROUND_GUARD 0
+#endif
+
+#ifndef BOOST_INTEL_CXX_VERSION
+#define BOOST_INTEL_CXX_VERSION_WORKAROUND_GUARD 1
+#else
+#define BOOST_INTEL_CXX_VERSION_WORKAROUND_GUARD 0
+#endif
+#ifndef BOOST_INTEL_WIN
+#define BOOST_INTEL_WIN_WORKAROUND_GUARD 1
+#else
+#define BOOST_INTEL_WIN_WORKAROUND_GUARD 0
+#endif
+#ifndef BOOST_DINKUMWARE_STDLIB
+#define BOOST_DINKUMWARE_STDLIB_WORKAROUND_GUARD 1
+#else
+#define BOOST_DINKUMWARE_STDLIB_WORKAROUND_GUARD 0
+#endif
+#ifndef BOOST_INTEL
+#define BOOST_INTEL_WORKAROUND_GUARD 1
+#else
+#define BOOST_INTEL_WORKAROUND_GUARD 0
+#endif
+// Always define to zero, if it's used it'll be defined my MPL:
+#define BOOST_MPL_CFG_GCC_WORKAROUND_GUARD 0
+
# define BOOST_WORKAROUND(symbol, test) \
- ((symbol != 0) && (1 % (( (symbol test) ) + 1)))
+ ((symbol ## _WORKAROUND_GUARD + 0 == 0) && \
+ (symbol != 0) && (1 % (( (symbol test) ) + 1)))
// ^ ^ ^ ^
// The extra level of parenthesis nesting above, along with the
// BOOST_OPEN_PAREN indirection below, is required to satisfy the
diff --git a/include/boost/version.hpp b/include/boost/version.hpp
index 6c18adc3..90a54ba2 100644
--- a/include/boost/version.hpp
+++ b/include/boost/version.hpp
@@ -19,17 +19,15 @@
// BOOST_VERSION / 100 % 1000 is the minor version
// BOOST_VERSION / 100000 is the major version
-#define BOOST_VERSION 103401
+#define BOOST_VERSION 103500
//
// BOOST_LIB_VERSION must be defined to be the same as BOOST_VERSION
// but as a *string* in the form "x_y" where x is the major version
-// number and y is the minor version number, or in the form "x_y_z"
-// where z is the patch version number when the patch version number
-// is not zero (z > 0). This is used by to
-// select which library version to link to.
+// number and y is the minor version number. This is used by
+// to select which library version to link to.
-#define BOOST_LIB_VERSION "1_34_1"
+#define BOOST_LIB_VERSION "1_35"
#endif
diff --git a/index.html b/index.html
index 77ec5480..df7430bd 100644
--- a/index.html
+++ b/index.html
@@ -1,10 +1,10 @@
-
+
- Automatic redirection failed, please go to config.htm.
+ Automatic redirection failed, please go to doc/html/index.html.