From 512fdec421a6964ccf9fb1588bdeb956add9719b Mon Sep 17 00:00:00 2001 From: John Maddock Date: Fri, 23 May 2003 11:10:34 +0000 Subject: [PATCH] Added new config macro: BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE [SVN r18507] --- config.htm | 2631 ++++++++++++--------------- test/Jamfile | 5 +- test/boost_no_using_decl_overld.ipp | 33 + test/config_test.cpp | 8 +- test/no_using_decl_overld_fail.cpp | 35 + test/no_using_decl_overld_pass.cpp | 35 + tools/generate | 5 +- 7 files changed, 1297 insertions(+), 1455 deletions(-) create mode 100644 test/boost_no_using_decl_overld.ipp create mode 100644 test/no_using_decl_overld_fail.cpp create mode 100644 test/no_using_decl_overld_pass.cpp diff --git a/config.htm b/config.htm index 85fc9c77..daadf429 100644 --- a/config.htm +++ b/config.htm @@ -1,24 +1,15 @@ - - - - - - - - - - -

Boost

- -

Boost Configuration Reference

- -

Contents

- -
Configuring Boost for Your Platform
+   
+      
+      
+      
+      
+   
+   
+      
Boost

+      
Boost Configuration Reference

+      
Contents

+      
Configuring Boost for Your Platform
    Using the default boost configuration
    The <boost\config.hpp> header
    Using the configure script
@@ -36,1275 +27,1073 @@ width="277" height="86">

    Modifying the Boost Configuration Headers
 Rationale
 Acknowledgements

-
-
Configuring Boost for Your Platform

-
-
Using the default boost
-configuration

-
-
Boost is 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. 

-
-
The <boost/config.hpp>
-header

-
-
Boost library implementations access configuration macros via #include
-<boost/config.hpp>. 

-
-
Boost library users are never required to #include
-<boost/config.hpp>, and are discouraged from doing
-so on their own. It is an implementation detail which is subject
-to change, and thus should not be depended upon by users. 

-
-
Using the configure script

-
-
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:

-
-
./configure

-
-
you will see a list of the items being checked as the script
-works it 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 then
-you will need to set one or more of the following environment
-variables:

-
-
-    
-        
-        
-    
-    
-        
-        
-    
-    
-        
-        
-    
-    
-        
-        
-    
-    
-        
-        
-    
-
Variable

-        
Description

-        
CXXThe name of the compiler,
-        for example "c++".
CXXFLAGSThe compiler flags to use,
-        for example "-O2".
LDFLAGSThe linker flags to use, for
-        example "-L/mypath".
LIBSAny 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"
+      
Configuring Boost for Your Platform

+      
Using the default boost configuration

+      
Boost is 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.
+      

+      
The <boost/config.hpp> 
+            header

+      
Boost library implementations access configuration macros via #include 
+            <boost/config.hpp>.
+      

+      
Boost library users are never required to #include <boost/config.hpp>, 
+         and are discouraged from doing so on their own. It is an implementation detail 
+         which is subject to change, and thus should not be depended upon by users.
+      

+      
Using the configure script

+      
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:

+      
./configure

+      
you will see a list of the items being checked as the script works it 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 then you will need to set one or more of the following 
+         environment variables:

+      
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+         
+            
+            
+         
+      
Variable

+            
Description

+            
CXXThe name of the compiler, for example "c++".
CXXFLAGSThe compiler flags to use, for example "-O2".
LDFLAGSThe linker flags to use, for example "-L/mypath".
LIBSAny 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"
 ./configure

-
-
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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGEquivalent to defining all
-        of BOOST_NO_COMPILER_CONFIG, BOOST_NO_STDLIB_CONFIG and
-        BOOST_NO_PLATFORM_CONFIG.
BOOST_STRICT_CONFIGThe 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_CONFIGWhen 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_THREADSWhen defined, disables
-        threading support, even if the compiler in its current
-        translation mode supports multiple threads.
BOOST_DISABLE_WIN32When 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".

-
-
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:

-
-
#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.

-
-
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.cppPrints 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.cppA 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.cppTests 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.cppIndividual 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.cppIndividual 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.cppIndividual 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.cppIndividual 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_BUGCompilerThe compiler exibits certain partial specialisation
-        bug - probably Borland C++ Builder specific.
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUPCompilerCompiler does not implement
-        argument-dependent lookup (also named Koenig lookup); see
-        std::3.4.2 [basic.koenig.lookup]
BOOST_NO_AUTO_PTRStandard libraryIf the compiler / library
-        supplies non-standard or broken std::auto_ptr.
BOOST_NO_CTYPE_FUNCTIONSPlatformThe Platform does not
-        provide functions for the character-classifying
-        operations <ctype.h> and <cctype>, only
-        macros.
BOOST_NO_CV_SPECIALIZATIONSCompilerIf template specialisations
-        for cv-qualified types conflict with a specialisation for
-        a cv-unqualififed type.
BOOST_NO_CV_VOID_SPECIALIZATIONSCompilerIf template specialisations
-        for cv-void types conflict with a specialisation for void.
BOOST_NO_CWCHARPlatformThe Platform does not
-        provide <wchar.h> and <cwchar>.
BOOST_NO_CWCTYPEPlatformThe Platform does not
-        provide <wctype.h> and <cwctype>.
BOOST_NO_DEPENDENT_NESTED_DERIVATIONSCompilerThe compiler fails to
-        compile a nested class that has a dependent base class:
template<typename T>
+      
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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGWhen 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_CONFIGEquivalent to defining all of 
+               BOOST_NO_COMPILER_CONFIG, BOOST_NO_STDLIB_CONFIG and BOOST_NO_PLATFORM_CONFIG.
BOOST_STRICT_CONFIGThe 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_CONFIGWhen 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_THREADSWhen defined, disables threading support, even if the 
+               compiler in its current translation mode supports multiple threads.
BOOST_DISABLE_WIN32When 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".

+      
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:

+      
#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.

+      
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.cppPrints 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.cppA 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.cppTests 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.cppIndividual 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.cppIndividual 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.cppIndividual 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.cppIndividual 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_BUGCompilerThe compiler exibits certain partial specialisation bug - probably Borland C++ 
+               Builder specific.
BOOST_NO_ARGUMENT_DEPENDENT_LOOKUPCompilerCompiler does not implement argument-dependent lookup 
+               (also named Koenig lookup); see std::3.4.2 [basic.koenig.lookup]
BOOST_NO_AUTO_PTRStandard libraryIf the compiler / library supplies non-standard or 
+               broken std::auto_ptr.
BOOST_NO_CTYPE_FUNCTIONSPlatformThe Platform does not provide functions for the 
+               character-classifying operations <ctype.h> and <cctype>, only 
+               macros.
BOOST_NO_CV_SPECIALIZATIONSCompilerIf template specialisations for cv-qualified types 
+               conflict with a specialisation for a cv-unqualififed type.
BOOST_NO_CV_VOID_SPECIALIZATIONSCompilerIf template specialisations for cv-void types 
+               conflict with a specialisation for void.
BOOST_NO_CWCHARPlatformThe Platform does not provide <wchar.h> and 
+               <cwchar>.
BOOST_NO_CWCTYPEPlatformThe Platform does not provide <wctype.h> and 
+               <cwctype>.
BOOST_NO_DEPENDENT_NESTED_DERIVATIONSCompilerThe 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 {};
 };

-        
BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERSCompilerTemplate value parameters
-        cannot have a dependent type, for example:
template<class T, typename T::type value> 
+            
BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERSCompilerTemplate value parameters cannot have a dependent 
+               type, for example:
template<class T, typename T::type value> 
 class X { ... };

-        
BOOST_NO_EXCEPTION_STD_NAMESPACEStandard LibraryThe standard library does not put some or all of the
-        contents of <exception> in namespace std.
BOOST_NO_EXCEPTIONSCompilerThe 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_ARGUMENTSCompilerCan only use deduced
-        template arguments when calling function template
-        instantiations.
BOOST_NO_FUNCTION_TEMPLATE_ORDERINGCompilerThe compiler does not
-        perform function template ordering or its function
-        template ordering is incorrect. 
template<typename T> void f(T); // #1
+            
BOOST_NO_EXCEPTION_STD_NAMESPACEStandard LibraryThe standard library does not put some or all of the contents of 
+               <exception> in namespace std.
BOOST_NO_EXCEPTIONSCompilerThe 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_ARGUMENTSCompilerCan only use deduced template arguments when calling 
+               function template instantiations.
BOOST_NO_FUNCTION_TEMPLATE_ORDERINGCompilerThe compiler does not perform function template 
+               ordering or its function template ordering is incorrect.
+               
template<typename T> void f(T); // #1
 template<typename T, typename U> void f(T (*)(U)); // #2
 
 void bar(int);
 
 f(&bar); // should choose #2.

-        
BOOST_NO_INCLASS_MEMBER_INITIALIZATIONCompilerCompiler violates std::9.4.2/4.
BOOST_NO_INTRINSIC_WCHAR_TCompilerThe 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_LIMITSStandard libraryThe 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_CONSTANTSStandard libraryConstants such as
-        numeric_limits<T>::is_signed are not available for
-        use at compile-time.
BOOST_NO_LONG_LONG_NUMERIC_LIMITSStandard libraryThere 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_SPECIALIZATIONSCompilerThe compiler does not support the specialization of
-        individual member functions of template classes.
BOOST_NO_MEMBER_TEMPLATE_KEYWORDCompilerIf the compiler supports
-        member templates, but not the template keyword when
-        accessing member template classes.
BOOST_NO_MEMBER_TEMPLATE_FRIENDSCompilerMember template friend
-        syntax ("template<class P> friend class frd;")
-        described in the C++ Standard, 14.5.3, not supported.
BOOST_NO_MEMBER_TEMPLATESCompilerMember template functions
-        not fully supported.
BOOST_NO_MS_INT64_NUMERIC_LIMITSStandard libraryThere 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_NAMESPACECompilerCompiler 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_CONSTCompilerThe 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_PRIVATE_IN_AGGREGATECompilerThe compiler misreads 8.5.1,
-        treating classes as non-aggregate if they contain private
-        or protected member functions.
BOOST_NO_STD_ALLOCATORStandard libraryThe C++ standard library
-        does not provide a standards conforming std::allocator.
BOOST_NO_STD_DISTANCEStandard libraryThe platform does not have a
-        conforming version of std::distance.
BOOST_NO_STD_ITERATORStandard libraryThe C++ implementation fails
-        to provide the std::iterator class.
BOOST_NO_STD_ITERATOR_TRAITSStandard libraryThe 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_LOCALEStandard libraryThe standard library lacks
-        std::locale.
BOOST_NO_STD_MESSAGESStandard libraryThe standard library lacks a
-        conforming std::messages facet.
BOOST_NO_STD_MIN_MAXStandard libraryThe C++ standard library
-        does not provide the min() and max() template functions
-        that should be in <algorithm>.
BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGNStandard libraryDefined if the standard library's output
-        iterators are not assignable.
BOOST_NO_STD_USE_FACETStandard libraryThe standard library lacks a
-        conforming std::use_facet.
BOOST_NO_STD_WSTREAMBUFStandard libraryThe standard library's implementation of std::basic_streambuf<wchar_t>
-        is either missing, incomplete, or buggy.
BOOST_NO_STD_WSTRINGStandard libraryThe standard library lacks
-        std::wstring.
BOOST_NO_STDC_NAMESPACECompiler/PlatformThe 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_STRINGSTREAMStandard libraryThe C++ implementation does
-        not provide the <sstream> header.
BOOST_NO_SWPRINTFPlatformThe platform does not have a
-        conforming version of swprintf.
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATIONCompilerClass template partial
-        specialization (14.5.4 [temp.class.spec]) not supported.
BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORSStandard libraryThe standard library does
-        not provide templated iterator constructors for its
-        containers.
BOOST_NO_TEMPLATE_TEMPLATESCompilerThe compiler does not support template template
-        parameters.
BOOST_NO_UNREACHABLE_RETURN_DETECTIONCompilerIf 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_TEMPLATECompilerThe 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_RETURNSCompilerThe compiler does not allow
-        a void function to return the result of calling another
-        void function. 
void f() {}
+            
BOOST_NO_INCLASS_MEMBER_INITIALIZATIONCompilerCompiler violates std::9.4.2/4.
BOOST_NO_INTRINSIC_WCHAR_TCompilerThe 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_LIMITSStandard libraryThe 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_CONSTANTSStandard libraryConstants such as numeric_limits<T>::is_signed 
+               are not available for use at compile-time.
BOOST_NO_LONG_LONG_NUMERIC_LIMITSStandard libraryThere 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_SPECIALIZATIONSCompilerThe compiler does not support the specialization of individual member 
+               functions of template classes.
BOOST_NO_MEMBER_TEMPLATE_KEYWORDCompilerIf the compiler supports member templates, but not 
+               the template keyword when accessing member template classes.
BOOST_NO_MEMBER_TEMPLATE_FRIENDSCompilerMember template friend syntax ("template<class 
+               P> friend class frd;") described in the C++ Standard, 14.5.3, not supported.
BOOST_NO_MEMBER_TEMPLATESCompilerMember template functions not fully supported.
BOOST_NO_MS_INT64_NUMERIC_LIMITSStandard libraryThere 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_NAMESPACECompilerCompiler 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_CONSTCompilerThe 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_PRIVATE_IN_AGGREGATECompilerThe compiler misreads 8.5.1, treating classes as 
+               non-aggregate if they contain private or protected member functions.
BOOST_NO_STD_ALLOCATORStandard libraryThe C++ standard library does not provide a standards 
+               conforming std::allocator.
BOOST_NO_STD_DISTANCEStandard libraryThe platform does not have a conforming version of 
+               std::distance.
BOOST_NO_STD_ITERATORStandard libraryThe C++ implementation fails to provide the 
+               std::iterator class.
BOOST_NO_STD_ITERATOR_TRAITSStandard libraryThe 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_LOCALEStandard libraryThe standard library lacks std::locale.
BOOST_NO_STD_MESSAGESStandard libraryThe standard library lacks a conforming std::messages 
+               facet.
BOOST_NO_STD_MIN_MAXStandard libraryThe C++ standard library does not provide the min() 
+               and max() template functions that should be in <algorithm>.
BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGNStandard libraryDefined if the standard library's output iterators are not 
+               assignable.
BOOST_NO_STD_USE_FACETStandard libraryThe standard library lacks a conforming 
+               std::use_facet.
BOOST_NO_STD_WSTREAMBUFStandard libraryThe standard library's implementation of std::basic_streambuf<wchar_t> 
+               is either missing, incomplete, or buggy.
BOOST_NO_STD_WSTRINGStandard libraryThe standard library lacks std::wstring.
BOOST_NO_STDC_NAMESPACECompiler/PlatformThe 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_STRINGSTREAMStandard libraryThe C++ implementation does not provide the 
+               <sstream> header.
BOOST_NO_SWPRINTFPlatformThe platform does not have a conforming version of 
+               swprintf.
BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATIONCompilerClass template partial specialization (14.5.4 
+               [temp.class.spec]) not supported.
BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORSStandard libraryThe standard library does not provide templated 
+               iterator constructors for its containers.
BOOST_NO_TEMPLATE_TEMPLATESCompilerThe compiler does not support template template parameters.
BOOST_NO_UNREACHABLE_RETURN_DETECTIONCompilerIf 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_BASECompilerThe 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_TEMPLATECompilerThe 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_RETURNSCompilerThe 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_BETHREADSPlatformThe platform supports BeOS
-        style threads.
BOOST_HAS_CLOCK_GETTIMEPlatformThe platform has the POSIX API clock_gettime.
BOOST_HAS_DIRENT_HPlatformThe platform has the POSIX header <dirent.h>.
BOOST_HAS_FTIMEPlatformThe platform has the Win32 API
-        GetSystemTimeAsFileTime.
BOOST_HAS_GETTIMEOFDAYPlatformThe platform has the POSIX API gettimeofday.
BOOST_HAS_HASHStandard libraryThe C++ implementation
-        provides the (SGI) hash_set or hash_map classes.
BOOST_HAS_LONG_LONGCompilerThe compiler supports the long long data type.
BOOST_HAS_MACRO_USE_FACETStandard libraryThe 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_INT64CompilerThe compiler supports the __int64 data type.
BOOST_HAS_NANOSLEEPPlatformThe platform has the POSIX API nanosleep.
BOOST_HAS_NL_TYPES_HPlatformThe platform has an
-        <nl_types.h>.
BOOST_HAS_NRVOCompilerIndicated 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_ALLOCATORStandard LibraryThe standard library has a partially conforming std::allocator
-        class, but without any of the member templates.
BOOST_HAS_PTHREAD_DELAY_NPPlatformThe platform has the POSIX API pthread_delay_np.
BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPEPlatformThe platform has the POSIX API
-        pthread_mutexattr_settype.
BOOST_HAS_PTHREAD_YIELDPlatformThe platform has the POSIX API pthread_yield.
BOOST_HAS_PTHREADSPlatformThe platform support POSIX
-        style threads.
BOOST_HAS_SCHED_YIELDPlatformThe platform has the POSIX API sched_yield.
BOOST_HAS_SGI_TYPE_TRAITSCompiler/standard libraryThe compiler has native support for SGI style type
-        traits.
BOOST_HAS_STDINT_HPlatformThe platform has a <stdint.h>
BOOST_HAS_SLISTStandard libraryThe C++ implementation
-        provides the (SGI) slist class.
BOOST_HAS_STLP_USE_FACETStandard libraryThe 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_THREADSPlatform/compilerDefined if the compiler, in
-        its current translation mode, supports multiple threads
-        of execution.
BOOST_HAS_TWO_ARG_USE_FACETStandard libraryThe 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_HPlatformThe Platform provides
-        <unistd.h>.
BOOST_HAS_WINTHREADSPlatformThe platform supports MS
-        Windows style threads.
BOOST_MSVC_STD_ITERATORStandard libraryMicrosoft's broken version
-        of std::iterator is being used. This implies that std::iterator
-        takes no more than two template parameters.
BOOST_MSVC6_MEMBER_TEMPLATESCompilerMicrosoft 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_HPlatformThere 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_TYPENAMESome 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> void f(T, typename T::type);

-        
with:

-        
template <class T> void f(T, BOOST_DEDUCED_TYPENAME T::type);

-        
BOOST_STD_EXTENSION_NAMESPACEThe 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{
+            

+      
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_BETHREADSPlatformThe platform supports BeOS style threads.
BOOST_HAS_CLOCK_GETTIMEPlatformThe platform has the POSIX API clock_gettime.
BOOST_HAS_DIRENT_HPlatformThe platform has the POSIX header <dirent.h>.
BOOST_HAS_FTIMEPlatformThe platform has the Win32 API GetSystemTimeAsFileTime.
BOOST_HAS_GETTIMEOFDAYPlatformThe platform has the POSIX API gettimeofday.
BOOST_HAS_HASHStandard libraryThe C++ implementation provides the (SGI) hash_set or 
+               hash_map classes.
BOOST_HAS_LONG_LONGCompilerThe compiler supports the long long data type.
BOOST_HAS_MACRO_USE_FACETStandard libraryThe 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_INT64CompilerThe compiler supports the __int64 data type.
BOOST_HAS_NANOSLEEPPlatformThe platform has the POSIX API nanosleep.
BOOST_HAS_NL_TYPES_HPlatformThe platform has an <nl_types.h>.
BOOST_HAS_NRVOCompilerIndicated 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_ALLOCATORStandard LibraryThe standard library has a partially conforming std::allocator class, but 
+               without any of the member templates.
BOOST_HAS_PTHREAD_DELAY_NPPlatformThe platform has the POSIX API pthread_delay_np.
BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPEPlatformThe platform has the POSIX API pthread_mutexattr_settype.
BOOST_HAS_PTHREAD_YIELDPlatformThe platform has the POSIX API pthread_yield.
BOOST_HAS_PTHREADSPlatformThe platform support POSIX style threads.
BOOST_HAS_SCHED_YIELDPlatformThe platform has the POSIX API sched_yield.
BOOST_HAS_SGI_TYPE_TRAITSCompiler/standard libraryThe compiler has native support for SGI style type traits.
BOOST_HAS_STDINT_HPlatformThe platform has a <stdint.h>
BOOST_HAS_SLISTStandard libraryThe C++ implementation provides the (SGI) slist 
+               class.
BOOST_HAS_STLP_USE_FACETStandard libraryThe 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_THREADSPlatform/compilerDefined if the compiler, in its current translation 
+               mode, supports multiple threads of execution.
BOOST_HAS_TWO_ARG_USE_FACETStandard libraryThe 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_HPlatformThe Platform provides <unistd.h>.
BOOST_HAS_WINTHREADSPlatformThe platform supports MS Windows style threads.
BOOST_MSVC_STD_ITERATORStandard libraryMicrosoft's broken version of std::iterator is being 
+               used. This implies that std::iterator takes no more than two template 
+               parameters.
BOOST_MSVC6_MEMBER_TEMPLATESCompilerMicrosoft 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_HPlatformThere 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_TYPENAMESome 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> void f(T, typename T::type);

+               
with:

+               
template <class T> void f(T, BOOST_DEDUCED_TYPENAME T::type);

+            
BOOST_STD_EXTENSION_NAMESPACEThe 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{
+               
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_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_NESTED_TEMPLATEMember templates are
-        supported by some compilers even though they can't use
-        the A::template member<U> syntax, as a workaround
-        replace:
typedef typename A::template rebind<U> binder;

-        
with:

-        
typedef typename A::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__.

-
-
Boost Informational Macros

-
-
The following macros describe boost features; these are the
-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_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.

-
-

-
-
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 .cxx file with the
-following comments near the top:

-
-
//  MACRO:         BOOST_NO_FOO
+            
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_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_NESTED_TEMPLATEMember templates are supported by some compilers even 
+               though they can't use the A::template member<U> syntax, as a workaround 
+               replace:
typedef typename A::template rebind<U> binder;

+               
with:

+               
typedef typename A::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__.

+      
Boost Informational Macros

+      
The following macros describe boost features; these are the 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_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.

+      

+      
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 .cxx 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.cxx", 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{
+      
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.cxx", 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()
 {
@@ -1314,183 +1103,123 @@ int test()
 }
 
 }

-
-
Once the test code is in place, run the shell script "generate"
-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 script, and the config_test.cpp
-test program. If you can't run shell scripts on your platform
-then post a message on the boost mailing list, and someone will
-run it for you. 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.cxx". 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/user.hpp>
-is included by default, don't add extra code to this file unless
-you have to. If you do, please remember to update libs/config/tools/configure.in as
-well.

-
-
<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.

-
-
<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!

-
-
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
-change to one compiler's configuration (for example) does not
-effect 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.

-
-
 

-
-

-
-
© Beman Dawes 2001

-
-
© Vesa Karvonen 2001

-
-
© John Maddock 2001

-
-
 

-
-
 

-
-
 

-
-
 

-
-
 

-
-
\ No newline at end of file
+      
Once the test code is in place, run the shell script "generate" 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 
+         script, and the config_test.cpp test program. If you can't run shell scripts on 
+         your platform then post a message on the boost mailing list, and someone will 
+         run it for you. 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.cxx". 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/user.hpp> is 
+         included by default, don't add extra code to this file unless you have to. If 
+         you do, please remember to update libs/config/tools/configure.in
+         as well.

+      
<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.

+      
<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!

+      
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 change to one compiler's configuration (for 
+         example) does not effect 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.

+      
 

+      

+      
© Beman Dawes 2001

+      
© Vesa Karvonen 2001

+      
© John Maddock 2001

+      
 

+      
 

+      
 

+      
 

+      
 

+   
+
diff --git a/test/Jamfile b/test/Jamfile
index 5e4a3f3a..1874f2c4 100644
--- a/test/Jamfile
+++ b/test/Jamfile
@@ -1,6 +1,6 @@
 #
 # Regression test Jamfile for boost configuration setup.
-# This file was automatically generated on Thu Feb 13 12:10:01 GMTST 2003,
+# This file was automatically generated on Fri May 23 11:49:09 GMTST 2003,
 # do not edit by hand...
 #
 subproject libs/config/test ;
@@ -150,6 +150,9 @@ test-suite "BOOST_NO_SWPRINTF" :
 test-suite "BOOST_NO_TEMPLATE_TEMPLATES" : 
 [ run no_template_template_pass.cpp ../../test/build/boost_prg_exec_monitor ]
 [ compile-fail no_template_template_fail.cpp ../../test/build/boost_prg_exec_monitor ] ;
+test-suite "BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE" : 
+[ run no_using_decl_overld_pass.cpp ../../test/build/boost_prg_exec_monitor ]
+[ compile-fail no_using_decl_overld_fail.cpp ../../test/build/boost_prg_exec_monitor ] ;
 test-suite "BOOST_NO_USING_TEMPLATE" : 
 [ run no_using_template_pass.cpp ../../test/build/boost_prg_exec_monitor ]
 [ compile-fail no_using_template_fail.cpp ../../test/build/boost_prg_exec_monitor ] ;
diff --git a/test/boost_no_using_decl_overld.ipp b/test/boost_no_using_decl_overld.ipp
new file mode 100644
index 00000000..aeac58b2
--- /dev/null
+++ b/test/boost_no_using_decl_overld.ipp
@@ -0,0 +1,33 @@
+//  (C) Copyright Eric Friedman 2002. Permission to copy, use, modify, sell and
+//  distribute this software is granted provided this copyright notice appears
+//  in all copies. This software is provided "as is" without express or implied
+//  warranty, and with no claim as to its suitability for any purpose.
+
+//  MACRO:         BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+//  TITLE:         using declaration function overloads from a typename base
+//  DESCRIPTION:   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.
+
+namespace boost_no_using_declaration_overloads_from_typename_base {
+
+struct base
+{
+   static void f() { }
+};
+
+template 
+struct using_overloads_from_typename_base : Base
+{
+   using Base::f;
+   static T f(const T& t) { return t; }
+};
+
+int test()
+{
+   using_overloads_from_typename_base::f();
+   return using_overloads_from_typename_base::f(0);
+}
+
+}
diff --git a/test/config_test.cpp b/test/config_test.cpp
index e6fe25c4..f374d7b8 100644
--- a/test/config_test.cpp
+++ b/test/config_test.cpp
@@ -10,7 +10,7 @@
 
 // Do not edit this file, it was generated automatically by
 // ../tools/generate from boost_*.cxx on
-// Thu Feb 13 12:10:01 GMTST 2003
+// Fri May 23 11:49:09 GMTST 2003
 
 #include 
 #define BOOST_INCLUDE_MAIN
@@ -247,6 +247,11 @@ namespace boost_no_swprintf = empty_boost;
 #else
 namespace boost_no_template_templates = empty_boost;
 #endif
+#ifndef BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+#include "boost_no_using_decl_overld.cxx"
+#else
+namespace boost_no_using_declaration_overloads_from_typename_base = empty_boost;
+#endif
 #ifndef BOOST_NO_USING_TEMPLATE
 #include "boost_no_using_template.cxx"
 #else
@@ -408,6 +413,7 @@ int test_main( int, char *[] )
    BOOST_TEST(0 == boost_no_intrinsic_wchar_t::test());
    BOOST_TEST(0 == boost_no_void_returns::test());
    BOOST_TEST(0 == boost_no_using_template::test());
+   BOOST_TEST(0 == boost_no_using_declaration_overloads_from_typename_base::test());
    BOOST_TEST(0 == boost_no_template_templates::test());
    BOOST_TEST(0 == boost_no_swprintf::test());
    BOOST_TEST(0 == boost_no_stdc_namespace::test());
diff --git a/test/no_using_decl_overld_fail.cpp b/test/no_using_decl_overld_fail.cpp
new file mode 100644
index 00000000..c7c945d0
--- /dev/null
+++ b/test/no_using_decl_overld_fail.cpp
@@ -0,0 +1,35 @@
+
+//  (C) Copyright Boost.org 1999. Permission to copy, use, modify, sell and
+//  distribute this software is granted provided this copyright notice appears
+//  in all copies. This software is provided "as is" without express or implied
+//  warranty, and with no claim as to its suitability for any purpose.
+
+// Test file for macro BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+// This file should not compile, if it does then
+// BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE need not be defined.
+// see boost_no_using_decl_overld.cxx for more details
+
+// Do not edit this file, it was generated automatically by
+// ../tools/generate from boost_no_using_decl_overld.cxx on
+// Fri May 23 11:39:30 GMTST 2003
+
+// Must not have BOOST_ASSERT_CONFIG set; it defeats
+// the objective of this file:
+#ifdef BOOST_ASSERT_CONFIG
+#  undef BOOST_ASSERT_CONFIG
+#endif
+
+#include 
+#include "test.hpp"
+
+#ifdef BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+#include "boost_no_using_decl_overld.cxx"
+#else
+#error "this file should not compile"
+#endif
+
+int cpp_main( int, char *[] )
+{
+   return boost_no_using_declaration_overloads_from_typename_base::test();
+}  
+   
diff --git a/test/no_using_decl_overld_pass.cpp b/test/no_using_decl_overld_pass.cpp
new file mode 100644
index 00000000..78cc710d
--- /dev/null
+++ b/test/no_using_decl_overld_pass.cpp
@@ -0,0 +1,35 @@
+
+//  (C) Copyright Boost.org 1999. Permission to copy, use, modify, sell and
+//  distribute this software is granted provided this copyright notice appears
+//  in all copies. This software is provided "as is" without express or implied
+//  warranty, and with no claim as to its suitability for any purpose.
+
+// Test file for macro BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+// This file should compile, if it does not then
+// BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE needs to be defined.
+// see boost_no_using_decl_overld.cxx for more details
+
+// Do not edit this file, it was generated automatically by
+// ../tools/generate from boost_no_using_decl_overld.cxx on
+// Fri May 23 11:39:30 GMTST 2003
+
+// Must not have BOOST_ASSERT_CONFIG set; it defeats
+// the objective of this file:
+#ifdef BOOST_ASSERT_CONFIG
+#  undef BOOST_ASSERT_CONFIG
+#endif
+
+#include 
+#include "test.hpp"
+
+#ifndef BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE
+#include "boost_no_using_decl_overld.cxx"
+#else
+namespace boost_no_using_declaration_overloads_from_typename_base = empty_boost;
+#endif
+
+int cpp_main( int, char *[] )
+{
+   return boost_no_using_declaration_overloads_from_typename_base::test();
+}  
+   
diff --git a/tools/generate b/tools/generate
index 728b23eb..7b82f027 100644
--- a/tools/generate
+++ b/tools/generate
@@ -175,7 +175,7 @@ EOF
    echo "compile-fail libs/config/test/$basename""_fail.cpp" >> ../test/regression.cfg
    
    echo 'test-suite "'$macroname'" : ' >> ../test/Jamfile
-   echo "[ run $basename""_pass.cpp ../../test/build/prg_exec_monitor ]" >> ../test/Jamfile
+   echo "[ run $basename""_pass.cpp ../../test/build/boost_prg_exec_monitor ]" >> ../test/Jamfile
    echo "[ compile-fail $basename""_fail.cpp ../../test/build/boost_prg_exec_monitor ] ;" >> ../test/Jamfile
    
 done
@@ -299,7 +299,7 @@ EOF
    echo "compile-fail libs/config/test/$basename""_fail.cpp" >> ../test/regression.cfg
    
    echo 'test-suite "'$macroname'" : ' >> ../test/Jamfile
-   echo "[ run $basename""_pass.cpp ../../test/build/prg_exec_monitor ]" >> ../test/Jamfile
+   echo "[ run $basename""_pass.cpp ../../test/build/boost_prg_exec_monitor ]" >> ../test/Jamfile
    echo "[ compile-fail $basename""_fail.cpp ../../test/build/boost_prg_exec_monitor ] ;" >> ../test/Jamfile
 
 done
@@ -351,3 +351,4 @@ echo
 
 
 
+