|
+Home | +Libraries | +People | +FAQ | +More | +
+
+ Beman Dawes provided the original config.hpp and
+ part of this document.
+
+ Vesa Karvonen provided a description of the principles (see rationale) + and put together an early version of the current configuration setup. +
++ John Maddock put together the configuration current code, the test programs, + the configuration script and the reference section of this document. +
++ Matias Capeletto converted the docs to quickbook format. +
++ Numerous boost members, past and present, have contributed fixes to boost's + configuration. +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ The following macros all describe features that are required by the C++03 + standard, if one of the following macros is defined, then it represents a + defect in the compiler's conformance with the 2003 standard. +
+|
+ + Macro + + |
+
+ + Section + + |
+
+ + Description + + |
+
|---|---|---|
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler exibits certain partial specialisation bug - probably + Borland C++ Builder specific. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Argument dependent lookup fails if there is a using declaration
+ for the symbol being looked up in the current scope. For example,
+ using |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler locates and searches namespaces that it should *not* + in fact search when performing argument dependent lookup. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler does not implement argument-dependent lookup (also named + Koenig lookup); see std::3.4.2 [basic.koenig.lookup] + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ If the compiler / library supplies non-standard or broken |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler has not completely implemented value-initialization. See + also The + Utility/Value Init docs + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide functions for the character-classifying
+ operations |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If template specialisations for cv-qualified types conflict with + a specialisation for a cv-unqualififed type. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If template specialisations for cv-void types conflict with a specialisation + for void. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide |
+
|
+
+ |
+
+ + Platform, Standard library + + |
+
+
+ The C standard library doesn't provide |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler fails to compile a nested class that has a dependent + base class: + +template<typename T> +struct foo : { + template<typename U> + struct bar : public U {}; ++ + }; + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Template value parameters cannot have a dependent type, for example: + +template<class T, typename T::type value> +class X { ... }; ++ + + |
+
|
+
+ |
+
+ + Standard Library + + |
+
+
+ The standard library does not put some or all of the contents of
+ |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support exception handling (this setting + is typically required by many C++ compilers for embedded platforms). + Note that there is no requirement for boost libraries to honor + this configuration setting - indeed doing so may be impossible + in some cases. Those libraries that do honor this will typically + abort if a critical error occurs - you have been warned! + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Can only use deduced template arguments when calling function template + instantiations. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not perform function template ordering or its + function template ordering is incorrect. + +// #1 +template<class T> void f(T); + +// #2 +template<class T,class U> void f(T(*)(U)); + +void bar(int); + +f(&bar); // should choose #2. ++ + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler violates std::9.4.2/4. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The C++ implementation does not provide |
+
|
+
+ |
+
+ + std lib + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + std lib + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The C++ compiler does not support SFINAE with abstract types, this + is covered by Core + Language DR337, but is not part of the current standard. + Fortunately most compilers that support SFINAE also support this + DR. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation does not provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ C++11 additions to |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Constants such as |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ There is no specialization for |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the specialization of individual + member functions of template classes. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If the compiler supports member templates, but not the template + keyword when accessing member template classes. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Member template friend syntax ( |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Member template functions not fully supported. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ There is no specialization for |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler doesn't allow a nested class to access private members + of its containing class. Probably Borland/CodeGear specific. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Compiler requires inherited operator friend functions to be defined
+ at namespace scope, then using'ed to boost. Probably GCC specific.
+ See |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not correctly handle partial specializations + which depend upon default arguments in the primary template. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The compiler does not correctly handle pointers to const member
+ functions, preventing use of these in overloaded function templates.
+ See |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Pointers to members don't work when used as template parameters. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler misreads 8.5.1, treating classes as non-aggregate + if they contain private or protected member functions. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler may (or may not) have the typeid operator, but RTTI + on the dynamic type of an object is not supported. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the "Substitution Failure Is + Not An Error" meta-programming idiom. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support usage of SFINAE with arbitrary expressions. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ standard library does not provide a standards conforming
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The platform does not have a conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation fails to provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The compiler does not provide a standard compliant implementation
+ of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ standard library does not provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + Defined if the standard library's output iterators are not assignable. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The <typeinfo> header declares |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library's implementation of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Compiler, Platform + + |
+
+
+ The contents of C++ standard headers for C library functions (the
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation does not provide the |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform does not have a conforming version of |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Class template partial specialization (14.5.4 [temp.class.spec]) + not supported. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library does not provide templated iostream classes. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library does not provide templated iterator constructors + for its containers. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support template template parameters. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the typeid operator at all. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The typename keyword cannot be used when creating a temporary of + a Dependent type. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If a return is unreachable, then no return statement should be + required, however some compilers insist on it, while other issue + a bunch of warnings if it is in fact present. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler will not accept a using declaration that brings a + function from a typename used as a base class into a derived class + if functions of the same name are present in the derived class. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler will not accept a using declaration that imports a + template class or function from another namespace. Originally a + Borland specific problem with imports to/from the global namespace, + extended to MSVC6 which has a specific issue with importing template + classes (but not functions). + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not allow a void function to return the result + of calling another void function. + +void f() {} +void g() { return f(); } ++ + + |
+
+ 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 + + |
+
|---|---|---|
|
+
+ |
+
+ + Platform + + |
+
+ + The platform supports BeOS style threads. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX header |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the functions |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the Win32 API type FTIME. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the Win32 API GetSystemTimeAsFileTime. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation provides the (SGI) hash_set and hash_map
+ classes. When defined, |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the functions |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The compiler supports the |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the POSIX API nanosleep. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has an |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Indicated that the compiler supports the named return value optimization
+ (NRVO). Used to select the most efficient implementation for some
+ function. See |
+
|
+
+ |
+
+ + Standard Library + + |
+
+
+ The standard library has a partially conforming |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform support POSIX style threads. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Compiler, Standard library + + |
+
+ + The compiler has native support for SGI style type traits. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has a |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation provides the (SGI) slist class. When defined,
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has TR1 conforming reference wrappers in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming result_of template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming mem_fn function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming bind function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming function class template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming hash function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has the TR1 additions to |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Implies all the other |
+
|
+
+ |
+
+ + Platform, Compiler + + |
+
+ + Defined if the compiler, in its current translation mode, supports + multiple threads of execution. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library lacks a conforming std::use_facet, but has + a two argument version that does the job. This is primarily for + the Rogue Wave std lib. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform provides |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform supports MS Windows style threads. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Microsoft's broken version of |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Microsoft Visual C++ 6.0 has enough member template idiosyncrasies
+ (being polite) that |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ There are no 1998 C++ Standard headers |
+
+ The following macros describe features that may be included in some future + ISO C++ standard, but have not yet been approved for inclusion in the language. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + The compiler supports concepts. + + |
+
+ The following macros describe features in the 2011 ISO C++ standard, formerly + known as C++0x, that are not yet supported by a particular compiler or library. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ The standard library does not provide a C++11 version of |
+
|
+
+ |
+
+ + The standard library <memory> does not support atomic smart + pointer operations. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <array>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <chrono>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <codecvt>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <condition_variable>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <forward_list>. + + |
+
|
+
+ |
+
+ + The standard library does not provide a C++11 compatible version + of <functional>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <future>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <initializer_list>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <mutex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <random>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <ratio>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <regex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <system_error>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <thread>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <tuple>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <typeindex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <type_traits>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <unordered_map>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <unordered_set>. + + |
+
|
+
+ |
+
+ + The standard library header <memory> has no shared_ptr and + unique_ptr. + + |
+
|
+
+ |
+
+
+ The compiler does not support type deduction for variables declared
+ with the |
+
|
+
+ |
+
+
+ The compiler does not support type deduction for multiple variables
+ declared with the |
+
|
+
+ |
+
+
+ The compiler does not support type |
+
|
+
+ |
+
+
+ The compiler does not support type |
+
|
+
+ |
+
+ + The compiler does not support template aliases. + + |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support the extension to |
+
|
+
+ |
+
+
+ The compiler does not support defaulted ( |
+
|
+
+ |
+
+
+ The compiler does not support deleted ( |
+
|
+
+ |
+
+
+ The compiler does not support explicit conversion operators ( |
+
|
+
+ |
+
+
+ The compiler does not support explicit instantiation forward declarations
+ for templates ( |
+
|
+
+ |
+
+ + The compiler does not support default template arguments for function + templates. + + |
+
|
+
+ |
+
+ + The compiler does not support Lambdas. + + |
+
|
+
+ |
+
+ + The compiler does not allow to pass local classes as template parameters + (this macro intentionally does not control passing of unnamed types + as template parameters, see also N2657). + + |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+ + The compiler does not support range-based for statements. + + |
+
|
+
+ |
+
+ + The compiler does not support raw string literals. + + |
+
|
+
+ |
+
+ + The compiler does not support r-value references. + + |
+
|
+
+ |
+
+
+ The compiler does not support scoped enumerations ( |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+ + The standard library does not support <unordered_map> and + <unordered_set>. + + |
+
|
+
+ |
+
+
+ The compiler does not support Unicode ( |
+
|
+
+ |
+
+ + The compiler does not support the C++11 + Unified Initialization Syntax. + + |
+
|
+
+ |
+
+ + The compiler does not support variadic templates. + + |
+
|
+
+ |
+
+ + The compiler does not support variadic macros. + + |
+
+ The following macros allow use of C++11 features even with compilers that + do not yet provide compliant C++11 support. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ Some compilers don't support the use of constexpr tuple(); ++ + with: + +BOOST_CONSTEXPR tuple(); ++ + + |
+
|
+
+ |
+
+
+ Some compilers don't support the use of static constexpr UIntType xor_mask = a; ++ + with: + +static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; ++ + + |
+
|
+
+ |
+
+
+ This is a shortcut for static constexpr UIntType xor_mask = a; ++ + with: + +BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; ++ + + |
+
|
+ + +BOOST_NOEXCEPT +BOOST_NOEXCEPT_IF(Predicate) +BOOST_NOEXCEPT_EXPR(Expression) ++ + + |
+
+
+ If +
+ If + |
+
+ The following macros are either simple helpers, or macros that provide workarounds + for compiler/standard library defects. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + This macro is used where a compiler specific workaround is required + that is not otherwise described by one of the other Boost.Config + macros. To use the macro you must first + +#include <boost/detail/workaround.hpp> ++ + usage is then: + +#if BOOST_WORKAROUND(MACRONAME, CONDITION) + // workaround code goes here... +#else + // Standard conforming code goes here... +#endif ++
+ where
+ The macro can also be used with
+ For example + Note: the ultimate source of documentation + for this macro is in boost/detail/workaround.hpp. + + |
+
|
+
+ |
+
+ + Sometimes you have a function name with the same name as a C macro, + for example "min" and "max" member functions, + in which case one can prevent the function being expanded as a + macro using: + +someclass.min BOOST_PREVENT_MACRO_SUBSTITUTION(arg1, arg2); ++ + The following also works in most, but not all, contexts: + +(someclass.max)(arg1, arg2); ++ + + |
+
|
+
+ |
+
+
+ Some compilers don't support the use of typename for dependent
+ types in deduced contexts. This macro expands to nothing on those
+ compilers, and typename elsewhere. For example, replace: |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+ + The namespace used for std library extensions (hashtable classes + etc). + + |
+
|
+
+ |
+
+ + On compilers which don't allow in-class initialization of static + integral constant members, we must use enums as a workaround if + we want the constants to be available at compile-time. This macro + gives us a convenient way to declare such constants. For example + instead of: + +struct foo{ + static const int value = 2; +}; ++ + use: + +struct foo{ + BOOST_STATIC_CONSTANT(int, value = 2); +}; ++ + + |
+
|
+
+ |
+
+ + Normally evaluates to nothing, but evaluates to return x; if the + compiler requires a return, even when it can never be reached. + + |
+
|
+
+ |
+
+ + Some compilers silently "fold" different function template + instantiations if some of the template parameters don't appear + in the function parameter list. For instance: + +#include <iostream> +#include <ostream> +#include <typeinfo> + +template <int n> +void f() { std::cout << n << ' '; } + +template <typename T> +void g() { std::cout << typeid(T).name() << ' '; } + +int main() { + f<1>(); + f<2>(); + + g<int>(); + g<double>(); +} ++
+ incorrectly outputs template <int n> +void f(BOOST_EXPLICIT_TEMPLATE_NON_TYPE(int, n)) { ... } + +template <typename T> +void g(BOOST_EXPLICIT_TEMPLATE_TYPE(T)) { ... } ++ + Beware that they can declare (for affected compilers) a dummy defaulted + parameter, so they + ++ a) should be always invoked at the end of the parameter list + ++ b) can't be used if your function + template is multiply declared. + +
+ Furthermore, in order to add any needed comma separator, an |
+
|
+
+ |
+
+
+ When the standard library does not have a conforming |
+
|
+
+ |
+
+
+ When the standard library does not have a comforming |
+
|
+
+ |
+
+
+ Member templates are supported by some compilers even though they
+ can't use the |
+
|
+
+ |
+
+
+ Converts the parameter |
+
|
+
+ |
+
+ + 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__. + + |
+
|
+
+ |
+
+
+ This macro can be used in place of the + Usage example: + +template<class T> +BOOST_FORCEINLINE T& f(T& t) +{ + return t; +} ++ + +
+ Note that use of this macro can lead to cryptic error messages
+ with some compilers. Consider defining it to |
+
+ The following macros describe boost features; these are, generally speaking + the only boost macros that should be tested in user code. +
+|
+ + Macro + + |
+
+ + Header + + |
+
+ + Description + + |
+
|---|---|---|
|
+
+ |
+
+
+ |
+
+
+ Describes the boost version number in XYYYZZ format such that:
+ |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if there are no 64-bit integral types: |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if the compiler is really Microsoft Visual C++, as opposed
+ to one of the many other compilers that also define |
+
|
+
+ |
+
+
+ |
+
+ + Defined to a normalised 9 digit version of _MSC_FULL_VER (which + sometimes only has 8 digits), the macro has the form VVMMPPPPP + where VV is the major version number, MM is the minor version number, + and PPPPP is the compiler build number. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the compiler is an Intel compiler, takes the same value + as the compiler version macro. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined to 1 if the compiler is the Clang compiler. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the Windows platform API is available. + + |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if the dinkumware standard library is in use, takes the
+ same value as the Dinkumware library version macro |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the regex library does not support wide character regular + expressions. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name and version number of the + compiler in use. Mainly for debugging the configuration. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name and version number of the + standard library in use. Mainly for debugging the configuration. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name of the platform. Mainly + for debugging the configuration. + + |
+
+ The following have been deprecated; please use the replacements instead. + They will be removed in a future version of boost. +
+|
+ + Deprecated Macro + + |
+
+ + Replacement + + |
+
+ + When deprecated + + |
+
+ + When removed + + |
+
|---|---|---|---|
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
| + | ++ | ++ | ++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
+ The following macros and helper headers are of use to authors whose libraries + include separate source code, and are intended to address several issues: +
++ See Guidelines + for Authors of Boost Libraries Containing Separate Source +
++ Some compilers support C++ extensions that control which symbols will be + exported from shared libraries such as dynamic shared objects (DSO's) on + Unix-like systems or dynamic-link libraries (DLL's) on Windows. +
+
+ The Microsoft VC++ compiler has long supplied __declspec(dllexport) and __declspec(dllimport) extensions for this purpose, as do virtually
+ all other compilers targeting the Windows platform.
+
+ Modern versions of the GNU GCC compiler provide the __attribute__((visibility("default"))) extension to indicate that a symbol
+ should be exported. All other symbols may be hidden by using the -fvisibility-hidden
+ or -fvisibility-ms-compat compiler switches.
+
+ Boost supplies several macros to make it easier to manage symbol visibility + in a way that is portable between compilers and operating systems. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be exported from a shared library. If the compiler + has no such extension, the macro is defined with no replacement + text. + + |
+
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be imported from a shared library. If the compiler + has no such extension, the macro is defined with no replacement + text. + + |
+
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be globally visible. If the compiler has no such + extension, the macro is defined with no replacement text. Needed + for classes that are not otherwise exported, but are used by + RTTI. Examples include class for objects that will be thrown + as exceptions or used in dynamic_casts, across shared library + boundaries. For example, a header-only exception class might + look like this: + +class BOOST_SYMBOL_VISIBLE my_exception : public std::runtime_error { ... }; ++ + Without BOOST_SYMBOL_VISIBLE, it would be impossible to catch + my_exception thrown from a shared library compiled by GCC with + the -fvisibility=hidden option. + + |
+
|
+
+ |
+
+
+ The compiler has C++ extensions |
+
+ Typical usage: +
++ boost/foo/config.hpp +
+... +#if defined(BOOST_ALL_DYN_LINK) || defined(BOOST_FOO_DYN_LINK) +# if defined(BOOST_FOO_SOURCE) +# define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT +# else +# define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT +# endif +#else +# define BOOST_FOO_DECL +#endif +... ++
+ boost/foo/foo.hpp +
+#include <boost/foo/config.hpp> +... +class BOOST_FOO_DECL bar { ... }; +... +void BOOST_FOO_DECL f(); +... ++
+ boost/libs/foo/src/foo.cpp +
+#define BOOST_FOO_SOURCE +#include <boost/foo/foo.hpp> +... +void BOOST_FOO_DECL f() +{ + ... +} +... ++
+ When linking against a pre-compiled library it vital that the ABI used
+ by the compiler when building the library matches exactly
+ the ABI used by the code using the library. In this case ABI means things
+ like the struct packing arrangement used, the name mangling scheme used,
+ or the size of some types (enum types for example). This is separate from
+ things like threading support, or runtime library variations, which have
+ to be dealt with by build variants. To put this in perspective there is
+ one compiler (Borland's) that has so many compiler options that make subtle
+ changes to the ABI, that at least in theory there 3200 combinations, and
+ that's without considering runtime library variations. Fortunately these
+ variations can be managed by #pragma's
+ that tell the compiler what ABI to use for the types declared in your library.
+ In order to avoid sprinkling #pragma's
+ all over the boost headers, there are some prefix and suffix headers that
+ do the job. Typical usage is:
+
+ my_library.hpp +
+#ifndef MY_INCLUDE_GUARD +#define MY_INCLUDE_GUARD + +// all includes go here: ++#include <boost/config.hpp>+#include <whatever> + +#include <boost/config/abi_prefix.hpp>// must be the last #include + +namespace boost { + +// your code goes here + +} + +#include <boost/config/abi_suffix.hpp>// pops abi_prefix.hpp pragmas + +#endif // include guard +
+ my_library.cpp +
+... +// nothing special need be done in the implementation file +... ++
+ The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS,
+ or they can define BOOST_ABI_PREFIX
+ and/or BOOST_ABI_SUFFIX
+ to point to their own prefix/suffix headers if they so wish.
+
+ It is essential that users link to a build of a library which was built + against the same runtime library that their application will be built against + -if this does not happen then the library will not be binary compatible + with their own code- and there is a high likelihood that their application + will experience runtime crashes. These kinds of problems can be extremely + time consuming and difficult to debug, and often lead to frustrated users + and authors alike (simply selecting the right library to link against is + not as easy as it seems when their are 6-8 of them to chose from, and some + users seem to be blissfully unaware that there even are different runtimes + available to them). +
+
+ To solve this issue, some compilers allow source code to contain #pragma's that instruct the linker
+ which library to link against, all the user need do is include the headers
+ they need, place the compiled libraries in their library search path, and
+ the compiler and linker do the rest. Boost.config supports this via the
+ header <boost/config/auto_link.hpp>, before including this header one or
+ more of the following macros need to be defined:
+
+
BOOST_LIB_NAME+ Required: An identifier containing the basename of the library, for + example 'boost_regex'. +
BOOST_DYN_LINK+ Optional: when set link to dll rather than static library. +
BOOST_LIB_DIAGNOSTIC+ Optional: when set the header will print out the name of the library + selected (useful for debugging). +
+ If the compiler supports this mechanism, then it will be told to link against
+ the appropriately named library, the actual algorithm used to mangle the
+ name of the library is documented inside <boost/config/auto_link.hpp>
+ and has to match that used to create the libraries via bjam 's install
+ rules.
+
+ my_library.hpp +
+... +// +// Don't include auto-linking code if the user has disabled it by +// defining BOOST_ALL_NO_LIB, or BOOST_MY_LIBRARY_NO_LIB, or if this +// is one of our own source files (signified by BOOST_MY_LIBRARY_SOURCE): +// +#if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_MY_LIBRARY_NO_LIB) && !defined(BOOST_MY_LIBRARY_SOURCE) +# define BOOST_LIB_NAME boost_my_library +# ifdef BOOST_MY_LIBRARY_DYN_LINK +# define BOOST_DYN_LINK +# endif +# include <boost/config/auto_link.hpp> +#endif +... ++
+ my_library.cpp +
+// define BOOST_MY_LIBRARY_SOURCE so that the header knows that the +// library is being built (possibly exporting rather than importing code) +// +#define BOOST_MY_LIBRARY_SOURCE + +#include <boost/my_library/my_library.hpp> +... ++
| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ 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: +
+#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).
+ #include
+ <boost/config.hpp>" is the preferred way to obtain
+ configuration information not available from the standard headers such
+ as <climits>, etc.
+ <climits>, use those standard headers rather
+ than <boost/config.hpp>.
+ <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.
+ 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 header <boost/config/warning_disable.hpp>
+ can be used to disable certain compiler warnings that are hard or impossible
+ to otherwise remove.
+
+ Note that: +
++ Currently it disables the following warnings: +
+|
+ + Compiler + + |
+
+ + Warning + + |
+
|---|---|
|
+ + Visual C++ 8 and later + + |
+
+ + C4996: + Error 'function': was declared deprecated + + |
+
|
+ + Intel C++ + + |
+
+ + Warning 1786: relates to the use of "deprecated" standard + library functions rather like C4996 in Visual C++. + + |
+
+ When you need to add a new defect macro - either to fix a problem with an + existing library, or when adding a new library - distil the issue down to + a simple test case; often, at this point other (possibly better) workarounds + may become apparent. Secondly always post the test case code to the boost + mailing list and invite comments; remember that C++ is complex and that sometimes + what may appear a defect, may in fact turn out to be a problem with the authors + understanding of the standard. +
+
+ When you name the macro, follow the BOOST_NO_SOMETHING
+ naming convention, so that it's obvious that this is a macro reporting a
+ defect.
+
+ Finally, add the test program to the regression tests. You will need to place
+ the test case in a .ipp
+ file with the following comments near the top:
+
// MACRO: BOOST_NO_FOO +// TITLE: foo +// DESCRIPTION: If the compiler fails to support foo ++
+ These comments are processed by the autoconf script, so make sure the format
+ follows the one given. The file should be named "boost_no_foo.ipp",
+ where foo is the defect description - try and keep the file name under the
+ Mac 30 character filename limit though. You will also need to provide a function
+ prototype "int test()" that is declared in a namespace with
+ the same name as the macro, but in all lower case, and which returns zero
+ on success:
+
namespace boost_no_foo { +int test() +{ + // test code goes here: + // + return 0; +} + +} ++
+ Once the test code is in place in libs/config/test, updating the configuration + test system proceeds as: +
+libs/config/tools and run bjam.
+ This generates the .cpp
+ file test cases from the .ipp file, updates the libs/config/test/all/Jamfile.v2,
+ config_test.cpp and config_info.cpp.libs/config/test/all and run bjam
+ MACRONAME compiler-list,
+ where MACRONAME is the name of the new macro, and
+ compiler-list is a space separated
+ list of compilers to test with.**passed**.**passed**. If MACRONAME
+ is defined when it should not be defined, xxx_fail_test will not report
+ **passed**.libs/config/test and run bjam
+ config_info config_test
+ compiler-list.
+ config_info should build
+ and run cleanly for all the compilers in compiler-list
+ while config_test should
+ fail for those that have the defect, and pass for those that do not.
+ + Then you should: +
+
+ When you need to add a macro that describes a feature that the standard does
+ not require, follow the convention for adding a new defect macro (above),
+ but call the macro BOOST_HAS_FOO,
+ and name the test file "boost_has_foo.ipp".
+ Try not to add feature test macros unnecessarily, if there is a platform
+ specific macro that can already be used (for example _WIN32,
+ __BEOS__, or __linux) to identify the feature then use
+ that. Try to keep the macro to a feature group, or header name, rather than
+ one specific API (for example BOOST_HAS_NL_TYPES_H
+ rather than BOOST_HAS_CATOPEN).
+ If the macro describes a POSIX feature group, then add boilerplate code to
+ <boost/config/suffix.hpp>
+ to auto-detect the feature where possible (if you are wondering why we can't
+ use POSIX feature test macro directly, remember that many of these features
+ can be added by third party libraries, and are not therefore identified inside
+ <unistd.h>).
+
+ The aim of boost's configuration setup is that the configuration headers + should be relatively stable - a boost user should not have to recompile their + code just because the configuration for some compiler that they're not interested + in has changed. Separating the configuration into separate compiler/standard + library/platform sections provides for part of this stability, but boost + authors require some amount of restraint as well, in particular: +
++ <boost/config.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! +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ The problem with many traditional "textbook" implementations of configuration + headers (where all the configuration options are in a single "monolithic" + header) is that they violate certain fundamental software engineering principles + which would have the effect of making boost more fragile, more difficult to + maintain and more difficult to use safely. You can find a description of the + principles from the following + article. +
++ Consider a situation in which you are concurrently developing on multiple + platforms. Then consider adding a new platform or changing the platform definitions + of an existing platform. What happens? Everything, and this does literally + mean everything, recompiles. Isn't it quite absurd that adding a new platform, + which has absolutely nothing to do with previously existing platforms, means + that all code on all existing platforms needs to be recompiled? +
++ Effectively, there is an imposed physical dependency between platforms that + have nothing to do with each other. Essentially, the traditional solution + employed by configuration headers does not conform to the Open-Closed Principle: +
++ "A module should be open for extension but closed + for modification." +
+ Extending a traditional configuration header implies modifying existing code. +
++ Furthermore, consider the complexity and fragility of the platform detection + code. What if a simple change breaks the detection on some minor platform? + What if someone accidentally or on purpose (as a workaround for some other + problem) defines some platform dependent macros that are used by the detection + code? A traditional configuration header is one of the most volatile headers + of the entire library, and more stable elements of Boost would depend on + it. This violates the Stable Dependencies Principle: +
++ "Depend in the direction of stability." +
+ After even a minor change to a traditional configuration header on one minor + platform, almost everything on every platform should be tested if we follow + sound software engineering practice. +
+
+ Another important issue is that it is not always possible to submit changes
+ to <boost/config.hpp>.
+ Some boost users are currently working on platforms using tools and libraries
+ that are under strict Non-Disclosure Agreements. In this situation it is
+ impossible to submit changes to a traditional monolithic configuration header,
+ instead some method by which the user can insert their own configuration
+ code must be provided.
+
+ The approach taken by boost's configuration headers is to separate configuration + into three orthogonal parts: the compiler, the standard library and the platform. + Each compiler/standard library/platform gets its own mini-configuration header, + so that changes to one compiler's configuration (for example) does not affect + other compilers. In addition there are measures that can be taken both to + omit the compiler/standard library/platform detection code (so that adding + support to a new platform does not break dependencies), or to freeze the + configuration completely; providing almost complete protection against dependency + changes. +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
Copyright © 2001-2007 Beman Dawes, Vesa Karvonen, John + Maddock
+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +
+Table of Contents
++ Boost comes already configured for most common compilers and platforms; you + should be able to use boost "as is". Since the compiler is configured + separately from the standard library, the default configuration should work + even if you replace the compiler's standard library with a third-party standard + library (like STLport). +
++ Using boost "as is" without trying to reconfigure is the recommended + method for using boost. You can, however, run the configure script if you + want to, and there are regression tests provided that allow you to test the + current boost configuration with your particular compiler setup. +
++ Boost library users can request support for additional compilers or platforms + by visiting our Trac + and submitting a support request. +
++ Boost library implementations access configuration macros via +
+#include <boost/config.hpp> ++
+ While Boost library users are not required to include that file directly, + or use those configuration macros, such use is acceptable. The configuration + macros are documented as to their purpose, usage, and limitations which makes + them usable by both Boost library and user code. +
++ Boost informational or helper + macros are designed for use by Boost users as well as for our own internal + use. Note however, that the feature test + and defect test macros were designed + for internal use by Boost libraries, not user code, so they can change at + any time (though no gratuitous changes are made to them). Boost library problems + resulting from changes to the configuration macros are caught by the Boost + regression tests, so the Boost libraries are updated to account for those + changes. By contrast, Boost library user code can be adversely affected by + changes to the macros without warning. The best way to keep abreast of changes + to the macros used in user code is to monitor the discussions on the Boost + developers list. +
+![[Important]](../../../../doc/src/images/important.png) |
+Important | +
|---|---|
+ This configure script only sets up the Boost headers for use with a particular + compiler. It has no effect on Boost.Build, or how the libraries are built. + |
+ If you know that boost is incorrectly configured for your particular setup,
+ and you are on a UNIX like platform, then you may want to try and improve
+ things by running the boost configure script. From a shell command prompt
+ you will need to cd into <boost-root>/libs/config/
+ and type:
+
+
sh ./configure+
+ you will see a list of the items being checked as the script works its way + through the regression tests. Note that the configure script only really + auto-detects your compiler if it's called g++, c++ or CC. If you are using + some other compiler you will need to set one or more of the following environment + variables: +
+|
+ + Variable + + |
+
+ + Description + + |
+
|---|---|
|
+ + CXX + + |
+
+
+ The name of the compiler, for example |
+
|
+ + CXXFLAGS + + |
+
+
+ The compiler flags to use, for example |
+
|
+ + LDFLAGS + + |
+
+
+ The linker flags to use, for example |
+
|
+ + LIBS + + |
+
+
+ Any libraries to link in, for example |
+
+ For example to run the configure script with HP aCC, you might use something + like: +
+export CXX="aCC" +export CXXFLAGS="-Aa -DAportable -D__HPACC_THREAD_SAFE_RB_TREE \ + -DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE" +export LDFLAGS="-DAportable" +export LIBS="-lpthread" +sh ./configure ++
+ However you run the configure script, when it finishes you will find a new
+ header -user.hpp- located in the <boost-root>/libs/config/
+ directory. Note that configure does not install this
+ header into your boost include path by default. This header contains
+ all the options generated by the configure script, plus a header-section
+ that contains the user settable options from the default version of <boost/config/user.hpp>
+ (located under <boost-root>/boost/config/).
+ There are two ways you can use this header:
+
/boost/config/ so that it replaces the default user.hpp
+ provided by boost. This option allows only one configure-generated setup;
+ boost developers should avoid this option, as it incurs the danger of
+ accidentally committing a configure-modified <boost/config/user.hpp>
+ to the svn repository (something you will not be thanked for!).
+ BOOST_USER_CONFIG to point to it. For
+ example create a new sub-directory <boost-root>/boost/config/ user/, and copy the header there; for example
+ as multithread-gcc-config.hpp. Then, when compiling add the command
+ line option: -DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>",
+ and boost will use the new configuration header. This option allows you
+ to generate more than one configuration header, and to keep them separate
+ from the boost source - so that updates to the source do not interfere
+ with your configuration.
+
+ There are some configuration-options that represent user choices, rather
+ than compiler defects or platform specific options. These are listed in
+ <boost/config/user.hpp>
+ and at the start of a configure-generated user.hpp header.
+ You can define these on the command line, or by editing <boost/config/user.hpp>, they are listed in the following table:
+
|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ When defined, it should point to the name of the user configuration
+ file to include prior to any boost configuration files. When not
+ defined, defaults to |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the compiler configuration
+ file to use. Defining this cuts out the compiler selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are using gcc, then you could define BOOST_COMPILER_CONFIG
+ to |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the standard library
+ configuration file to use. Defining this cuts out the standard
+ library selection logic, and eliminates the dependency on the header
+ containing that logic. For example if you are using STLport, then
+ you could define |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the platform configuration
+ file to use. Defining this cuts out the platform selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are compiling on linux, then you could define
+ |
+
|
+
+ |
+
+
+ When defined, no compiler configuration file is selected or included,
+ define when the compiler is fully conformant with the standard,
+ or where the user header (see |
+
|
+
+ |
+
+
+ When defined, no standard library configuration file is selected
+ or included, define when the standard library is fully conformant
+ with the standard, or where the user header (see |
+
|
+
+ |
+
+
+ When defined, no platform configuration file is selected or included,
+ define when the platform is fully conformant with the standard
+ (and has no useful extra features), or where the user header (see
+ |
+
|
+
+ |
+
+
+ Equivalent to defining all of |
+
|
+
+ |
+
+ + The normal behavior for compiler versions that are newer than the + last known version, is to assume that they have all the same defects + as the last known version. By setting this define, then compiler + versions that are newer than the last known version are assumed + to be fully conforming with the standard. This is probably most + useful for boost developers or testers, and for those who want + to use boost to test beta compiler versions. + + |
+
|
+
+ |
+
+ + When this flag is set, if the config finds anything unknown, then + it will stop with a #error rather than continue. Boost regression + testers should set this define, as should anyone who wants to quickly + check whether boost is supported on their platform. + + |
+
|
+
+ |
+
+ + When defined, disables threading support, even if the compiler + in its current translation mode supports multiple threads. + + |
+
|
+
+ |
+
+
+ When defined, disables the use of Win32 specific API's, even when
+ these are available. Also has the effect of setting |
+
|
+
+ |
+
+ + Stops boost headers from including any prefix/suffix headers that + normally control things like struct packing and alignment. + + |
+
|
+
+ |
+
+ + A prefix header to include in place of whatever boost.config would + normally select, any replacement should set up struct packing and + alignment options as required. + + |
+
|
+
+ |
+
+ + A suffix header to include in place of whatever boost.config would + normally select, any replacement should undo the effects of the + prefix header. + + |
+
|
+
+ |
+
+
+ Forces all libraries that have separate source, to be linked as
+ dll's rather than static libraries on Microsoft Windows (this macro
+ is used to turn on |
+
|
+
+ |
+
+
+ Forces library "whatever" to be linked as a dll rather
+ than a static library on Microsoft Windows: replace the WHATEVER
+ part of the macro name with the name of the library that you want
+ to dynamically link to, for example use |
+
|
+
+ |
+
+ + Tells the config system not to automatically select which libraries + to link against. Normally if a compiler supports #pragma lib, then + the correct library build variant will be automatically selected + and linked against, simply by the act of including one of that + library's headers. This macro turns that feature off. + + |
+
|
+
+ |
+
+
+ Tells the config system not to automatically select which library
+ to link against for library "whatever", replace WHATEVER
+ in the macro name with the name of the library; for example |
+
|
+
+ |
+
+ + Causes the auto-linking code to output diagnostic messages indicating + the name of the library that is selected for linking. + + |
+
|
+
+ |
+
+ + Overrides the name of the toolset part of the name of library being + linked to; note if defined this must be defined to a quoted string + literal, for example "abc". + + |
+
+ By setting various macros on the compiler command line or by editing <boost/config/user.hpp>, + the boost configuration setup can be optimised in a variety of ways. +
+
+ Boost's configuration is structured so that the user-configuration is included
+ first (defaulting to <boost/config/user.hpp>
+ if BOOST_USER_CONFIG is not
+ defined). This sets up any user-defined policies, and gives the user-configuration
+ a chance to influence what happens next.
+
+ Next the compiler, standard library, and platform configuration files are
+ included. These are included via macros (BOOST_COMPILER_CONFIG
+ etc, see user settable macros),
+ and if the corresponding macro is undefined then a separate header that detects
+ which compiler/standard library/platform is in use is included in order to
+ set these. The config can be told to ignore these headers altogether if the
+ corresponding BOOST_NO_XXX
+ macro is set (for example BOOST_NO_COMPILER_CONFIG
+ to disable including any compiler configuration file - see
+ user settable macros).
+
+ Finally the boost configuration header, includes <boost/config/suffix.hpp>; + this header contains any boiler plate configuration code - for example where + one boost macro being set implies that another must be set also. +
++ The following usage examples represent just a few of the possibilities: +
+
+ Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0.
+ Lets suppose also that we don't intend to update our compiler or standard
+ library any time soon. In order to avoid breaking dependencies when we
+ update boost, we may want to "freeze" our configuration headers,
+ so that we only have to rebuild our project if the boost code itself has
+ changed, and not because the boost config has been updated for more recent
+ versions of Visual C++ or STLport. We'll start by realising that the configuration
+ files in use are: <boost/config/compiler/visualc.hpp> for the compiler, <boost/config/stdlib/stlport.hpp> for the standard library, and
+ <boost/config/platform/win32.hpp> for the platform. Next we'll
+ create our own private configuration directory: boost/config/mysetup/, and copy the configuration files into
+ there. Finally, open up <boost/config/user.hpp>
+ and edit the following defines:
+
#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. +
+
+ 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.
+
+ If you are working on a unix-like platform then you can use the configure + script to generate a "frozen" configuration based on your current + compiler setup - see using the configure + script for more details. +
+
+ The boost configuration library provides a full set of regression test programs
+ under the <boost-root>/boost/config/
+ test/
+ sub-directory:
+
|
+ + File + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + Prints out a detailed description of your compiler/standard library/platform + setup, plus your current boost configuration. The information provided + by this program useful in setting up the boost configuration files. + If you report that boost is incorrectly configured for your compiler/library/platform + then please include the output from this program when reporting + the changes required. + + |
+
|
+
+ |
+
+ + A monolithic test program that includes most of the individual + test cases. This provides a quick check to see if boost is correctly + configured for your compiler/library/platform. + + |
+
|
+
+ |
+
+
+ Tests your standard library's |
+
|
+
+ |
+
+
+ Individual compiler defect test files. Each of these should compile,
+ if one does not then the corresponding |
+
|
+
+ |
+
+
+ Individual compiler defect test files. Each of these should not
+ compile, if one does then the corresponding |
+
|
+
+ |
+
+
+ Individual feature test files. If one of these does not compile
+ then the corresponding |
+
|
+
+ |
+
+
+ Individual feature test files. If one of these does compile then
+ the corresponding |
+
+ Although you can run the configuration regression tests as individual test + files, there are rather a lot of them, so there are a couple of shortcuts + to help you out: +
++ If you have built the boost + regression test driver, then you can use this to produce a nice html + formatted report of the results using the supplied test file. +
++ Alternatively you can run the configure script like this: +
++
./configure + --enable-test+
+ in which case the script will test the current configuration rather than + creating a new one from scratch. +
+
+ If you are reporting the results of these tests for a new platform/library/compiler
+ then please include a log of the full compiler output, the output from config_info.cpp, and the pass/fail test results.
+
Last revised: November 20, 2012 at 20:32:39 GMT |
++ |
|
+Home | +Libraries | +People | +FAQ | +More | +
+
+ Beman Dawes provided the original config.hpp and
+ part of this document.
+
+ Vesa Karvonen provided a description of the principles (see rationale) + and put together an early version of the current configuration setup. +
++ John Maddock put together the configuration current code, the test programs, + the configuration script and the reference section of this document. +
++ Matias Capeletto converted the docs to quickbook format. +
++ Numerous boost members, past and present, have contributed fixes to boost's + configuration. +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ The following macros all describe features that are required by the C++03 + standard, if one of the following macros is defined, then it represents a + defect in the compiler's conformance with the 2003 standard. +
+|
+ + Macro + + |
+
+ + Section + + |
+
+ + Description + + |
+
|---|---|---|
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler exibits certain partial specialisation bug - probably + Borland C++ Builder specific. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Argument dependent lookup fails if there is a using declaration
+ for the symbol being looked up in the current scope. For example,
+ using |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler locates and searches namespaces that it should *not* + in fact search when performing argument dependent lookup. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler does not implement argument-dependent lookup (also named + Koenig lookup); see std::3.4.2 [basic.koenig.lookup] + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ If the compiler / library supplies non-standard or broken |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler has not completely implemented value-initialization. See + also The + Utility/Value Init docs + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide functions for the character-classifying
+ operations |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If template specialisations for cv-qualified types conflict with + a specialisation for a cv-unqualififed type. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If template specialisations for cv-void types conflict with a specialisation + for void. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform does not provide |
+
|
+
+ |
+
+ + Platform, Standard library + + |
+
+
+ The C standard library doesn't provide |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler fails to compile a nested class that has a dependent + base class: + +template<typename T> +struct foo : { + template<typename U> + struct bar : public U {}; ++ + }; + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Template value parameters cannot have a dependent type, for example: + +template<class T, typename T::type value> +class X { ... }; ++ + + |
+
|
+
+ |
+
+ + Standard Library + + |
+
+
+ The standard library does not put some or all of the contents of
+ |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support exception handling (this setting + is typically required by many C++ compilers for embedded platforms). + Note that there is no requirement for boost libraries to honor + this configuration setting - indeed doing so may be impossible + in some cases. Those libraries that do honor this will typically + abort if a critical error occurs - you have been warned! + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Can only use deduced template arguments when calling function template + instantiations. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not perform function template ordering or its + function template ordering is incorrect. + +// #1 +template<class T> void f(T); + +// #2 +template<class T,class U> void f(T(*)(U)); + +void bar(int); + +f(&bar); // should choose #2. ++ + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler violates std::9.4.2/4. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The C++ implementation does not provide |
+
|
+
+ |
+
+ + std lib + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + std lib + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The C++ compiler does not support SFINAE with abstract types, this + is covered by Core + Language DR337, but is not part of the current standard. + Fortunately most compilers that support SFINAE also support this + DR. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation does not provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ C++11 additions to |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Constants such as |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ There is no specialization for |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the specialization of individual + member functions of template classes. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If the compiler supports member templates, but not the template + keyword when accessing member template classes. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Member template friend syntax ( |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Member template functions not fully supported. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ There is no specialization for |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Compiler doesn't allow a nested class to access private members + of its containing class. Probably Borland/CodeGear specific. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Compiler requires inherited operator friend functions to be defined
+ at namespace scope, then using'ed to boost. Probably GCC specific.
+ See |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not correctly handle partial specializations + which depend upon default arguments in the primary template. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The compiler does not correctly handle pointers to const member
+ functions, preventing use of these in overloaded function templates.
+ See |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Pointers to members don't work when used as template parameters. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler misreads 8.5.1, treating classes as non-aggregate + if they contain private or protected member functions. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler may (or may not) have the typeid operator, but RTTI + on the dynamic type of an object is not supported. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the "Substitution Failure Is + Not An Error" meta-programming idiom. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support usage of SFINAE with arbitrary expressions. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ standard library does not provide a standards conforming
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The platform does not have a conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation fails to provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The compiler does not provide a standard compliant implementation
+ of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ standard library does not provide the |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + Defined if the standard library's output iterators are not assignable. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The <typeinfo> header declares |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library's implementation of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks |
+
|
+
+ |
+
+ + Compiler, Platform + + |
+
+
+ The contents of C++ standard headers for C library functions (the
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation does not provide the |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform does not have a conforming version of |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + Class template partial specialization (14.5.4 [temp.class.spec]) + not supported. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library does not provide templated iostream classes. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library does not provide templated iterator constructors + for its containers. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support template template parameters. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not support the typeid operator at all. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The typename keyword cannot be used when creating a temporary of + a Dependent type. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + If a return is unreachable, then no return statement should be + required, however some compilers insist on it, while other issue + a bunch of warnings if it is in fact present. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler will not accept a using declaration that brings a + function from a typename used as a base class into a derived class + if functions of the same name are present in the derived class. + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler will not accept a using declaration that imports a + template class or function from another namespace. Originally a + Borland specific problem with imports to/from the global namespace, + extended to MSVC6 which has a specific issue with importing template + classes (but not functions). + + |
+
|
+
+ |
+
+ + Compiler + + |
+
+ + The compiler does not allow a void function to return the result + of calling another void function. + +void f() {} +void g() { return f(); } ++ + + |
+
+ 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 + + |
+
|---|---|---|
|
+
+ |
+
+ + Platform + + |
+
+ + The platform supports BeOS style threads. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX header |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the functions |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the Win32 API type FTIME. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the Win32 API GetSystemTimeAsFileTime. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation provides the (SGI) hash_set and hash_map
+ classes. When defined, |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the functions |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ The compiler supports the |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform has the POSIX API nanosleep. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has an |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Indicated that the compiler supports the named return value optimization
+ (NRVO). Used to select the most efficient implementation for some
+ function. See |
+
|
+
+ |
+
+ + Standard Library + + |
+
+
+ The standard library has a partially conforming |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform support POSIX style threads. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has the POSIX API |
+
|
+
+ |
+
+ + Compiler, Standard library + + |
+
+ + The compiler has native support for SGI style type traits. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The platform has a |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The C++ implementation provides the (SGI) slist class. When defined,
+ |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The standard library lacks a conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has TR1 conforming reference wrappers in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming result_of template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming mem_fn function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming bind function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming function class template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming hash function template in |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has the TR1 additions to |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ The library has a TR1 conforming version of |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Implies all the other |
+
|
+
+ |
+
+ + Platform, Compiler + + |
+
+ + Defined if the compiler, in its current translation mode, supports + multiple threads of execution. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+ + The standard library lacks a conforming std::use_facet, but has + a two argument version that does the job. This is primarily for + the Rogue Wave std lib. + + |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ The Platform provides |
+
|
+
+ |
+
+ + Platform + + |
+
+ + The platform supports MS Windows style threads. + + |
+
|
+
+ |
+
+ + Standard library + + |
+
+
+ Microsoft's broken version of |
+
|
+
+ |
+
+ + Compiler + + |
+
+
+ Microsoft Visual C++ 6.0 has enough member template idiosyncrasies
+ (being polite) that |
+
|
+
+ |
+
+ + Platform + + |
+
+
+ There are no 1998 C++ Standard headers |
+
+ The following macros describe features that may be included in some future + ISO C++ standard, but have not yet been approved for inclusion in the language. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + The compiler supports concepts. + + |
+
+ The following macros describe features in the 2011 ISO C++ standard, formerly + known as C++0x, that are not yet supported by a particular compiler or library. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ The standard library does not provide a C++11 version of |
+
|
+
+ |
+
+ + The standard library <memory> does not support atomic smart + pointer operations. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <array>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <chrono>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <codecvt>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <condition_variable>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <forward_list>. + + |
+
|
+
+ |
+
+ + The standard library does not provide a C++11 compatible version + of <functional>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <future>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <initializer_list>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <mutex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <random>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <ratio>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <regex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <system_error>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <thread>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <tuple>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <typeindex>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <type_traits>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <unordered_map>. + + |
+
|
+
+ |
+
+ + The standard library does not provide header <unordered_set>. + + |
+
|
+
+ |
+
+ + The standard library header <memory> has no shared_ptr and + unique_ptr. + + |
+
|
+
+ |
+
+
+ The compiler does not support type deduction for variables declared
+ with the |
+
|
+
+ |
+
+
+ The compiler does not support type deduction for multiple variables
+ declared with the |
+
|
+
+ |
+
+
+ The compiler does not support type |
+
|
+
+ |
+
+
+ The compiler does not support type |
+
|
+
+ |
+
+ + The compiler does not support template aliases. + + |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support the extension to |
+
|
+
+ |
+
+
+ The compiler does not support defaulted ( |
+
|
+
+ |
+
+
+ The compiler does not support deleted ( |
+
|
+
+ |
+
+
+ The compiler does not support explicit conversion operators ( |
+
|
+
+ |
+
+
+ The compiler does not support explicit instantiation forward declarations
+ for templates ( |
+
|
+
+ |
+
+ + The compiler does not support default template arguments for function + templates. + + |
+
|
+
+ |
+
+ + The compiler does not support Lambdas. + + |
+
|
+
+ |
+
+ + The compiler does not allow to pass local classes as template parameters + (this macro intentionally does not control passing of unnamed types + as template parameters, see also N2657). + + |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+ + The compiler does not support range-based for statements. + + |
+
|
+
+ |
+
+ + The compiler does not support raw string literals. + + |
+
|
+
+ |
+
+ + The compiler does not support r-value references. + + |
+
|
+
+ |
+
+
+ The compiler does not support scoped enumerations ( |
+
|
+
+ |
+
+
+ The compiler does not support |
+
|
+
+ |
+
+ + The standard library does not support <unordered_map> and + <unordered_set>. + + |
+
|
+
+ |
+
+
+ The compiler does not support Unicode ( |
+
|
+
+ |
+
+ + The compiler does not support the C++11 + Unified Initialization Syntax. + + |
+
|
+
+ |
+
+ + The compiler does not support variadic templates. + + |
+
|
+
+ |
+
+ + The compiler does not support variadic macros. + + |
+
+ The following macros allow use of C++11 features even with compilers that + do not yet provide compliant C++11 support. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ Some compilers don't support the use of constexpr tuple(); ++ + with: + +BOOST_CONSTEXPR tuple(); ++ + + |
+
|
+
+ |
+
+
+ Some compilers don't support the use of static constexpr UIntType xor_mask = a; ++ + with: + +static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a; ++ + + |
+
|
+
+ |
+
+
+ This is a shortcut for static constexpr UIntType xor_mask = a; ++ + with: + +BOOST_STATIC_CONSTEXPR UIntType xor_mask = a; ++ + + |
+
|
+ + +BOOST_NOEXCEPT +BOOST_NOEXCEPT_IF(Predicate) +BOOST_NOEXCEPT_EXPR(Expression) ++ + + |
+
+
+ If +
+ If + |
+
+ The following macros are either simple helpers, or macros that provide workarounds + for compiler/standard library defects. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + This macro is used where a compiler specific workaround is required + that is not otherwise described by one of the other Boost.Config + macros. To use the macro you must first + +#include <boost/detail/workaround.hpp> ++ + usage is then: + +#if BOOST_WORKAROUND(MACRONAME, CONDITION) + // workaround code goes here... +#else + // Standard conforming code goes here... +#endif ++
+ where
+ The macro can also be used with
+ For example + Note: the ultimate source of documentation + for this macro is in boost/detail/workaround.hpp. + + |
+
|
+
+ |
+
+ + Sometimes you have a function name with the same name as a C macro, + for example "min" and "max" member functions, + in which case one can prevent the function being expanded as a + macro using: + +someclass.min BOOST_PREVENT_MACRO_SUBSTITUTION(arg1, arg2); ++ + The following also works in most, but not all, contexts: + +(someclass.max)(arg1, arg2); ++ + + |
+
|
+
+ |
+
+
+ Some compilers don't support the use of typename for dependent
+ types in deduced contexts. This macro expands to nothing on those
+ compilers, and typename elsewhere. For example, replace: |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+
+ The header to include to get the SGI |
+
|
+
+ |
+
+ + The namespace used for std library extensions (hashtable classes + etc). + + |
+
|
+
+ |
+
+ + On compilers which don't allow in-class initialization of static + integral constant members, we must use enums as a workaround if + we want the constants to be available at compile-time. This macro + gives us a convenient way to declare such constants. For example + instead of: + +struct foo{ + static const int value = 2; +}; ++ + use: + +struct foo{ + BOOST_STATIC_CONSTANT(int, value = 2); +}; ++ + + |
+
|
+
+ |
+
+ + Normally evaluates to nothing, but evaluates to return x; if the + compiler requires a return, even when it can never be reached. + + |
+
|
+
+ |
+
+ + Some compilers silently "fold" different function template + instantiations if some of the template parameters don't appear + in the function parameter list. For instance: + +#include <iostream> +#include <ostream> +#include <typeinfo> + +template <int n> +void f() { std::cout << n << ' '; } + +template <typename T> +void g() { std::cout << typeid(T).name() << ' '; } + +int main() { + f<1>(); + f<2>(); + + g<int>(); + g<double>(); +} ++
+ incorrectly outputs template <int n> +void f(BOOST_EXPLICIT_TEMPLATE_NON_TYPE(int, n)) { ... } + +template <typename T> +void g(BOOST_EXPLICIT_TEMPLATE_TYPE(T)) { ... } ++ + Beware that they can declare (for affected compilers) a dummy defaulted + parameter, so they + ++ a) should be always invoked at the end of the parameter list + ++ b) can't be used if your function + template is multiply declared. + +
+ Furthermore, in order to add any needed comma separator, an |
+
|
+
+ |
+
+
+ When the standard library does not have a conforming |
+
|
+
+ |
+
+
+ When the standard library does not have a comforming |
+
|
+
+ |
+
+
+ Member templates are supported by some compilers even though they
+ can't use the |
+
|
+
+ |
+
+
+ Converts the parameter |
+
|
+
+ |
+
+ + 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__. + + |
+
|
+
+ |
+
+
+ This macro can be used in place of the + Usage example: + +template<class T> +BOOST_FORCEINLINE T& f(T& t) +{ + return t; +} ++ + +
+ Note that use of this macro can lead to cryptic error messages
+ with some compilers. Consider defining it to |
+
+ The following macros describe boost features; these are, generally speaking + the only boost macros that should be tested in user code. +
+|
+ + Macro + + |
+
+ + Header + + |
+
+ + Description + + |
+
|---|---|---|
|
+
+ |
+
+
+ |
+
+
+ Describes the boost version number in XYYYZZ format such that:
+ |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if there are no 64-bit integral types: |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if the compiler is really Microsoft Visual C++, as opposed
+ to one of the many other compilers that also define |
+
|
+
+ |
+
+
+ |
+
+ + Defined to a normalised 9 digit version of _MSC_FULL_VER (which + sometimes only has 8 digits), the macro has the form VVMMPPPPP + where VV is the major version number, MM is the minor version number, + and PPPPP is the compiler build number. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the compiler is an Intel compiler, takes the same value + as the compiler version macro. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined to 1 if the compiler is the Clang compiler. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the Windows platform API is available. + + |
+
|
+
+ |
+
+
+ |
+
+
+ Defined if the dinkumware standard library is in use, takes the
+ same value as the Dinkumware library version macro |
+
|
+
+ |
+
+
+ |
+
+ + Defined if the regex library does not support wide character regular + expressions. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name and version number of the + compiler in use. Mainly for debugging the configuration. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name and version number of the + standard library in use. Mainly for debugging the configuration. + + |
+
|
+
+ |
+
+
+ |
+
+ + Defined as a string describing the name of the platform. Mainly + for debugging the configuration. + + |
+
+ The following have been deprecated; please use the replacements instead. + They will be removed in a future version of boost. +
+|
+ + Deprecated Macro + + |
+
+ + Replacement + + |
+
+ + When deprecated + + |
+
+ + When removed + + |
+
|---|---|---|---|
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.50 + + |
++ | +
| + | ++ | ++ | ++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
|
+
+ |
+
+
+ |
+
+ + Boost 1.51 + + |
++ | +
+ The following macros and helper headers are of use to authors whose libraries + include separate source code, and are intended to address several issues: +
++ See Guidelines + for Authors of Boost Libraries Containing Separate Source +
++ Some compilers support C++ extensions that control which symbols will be + exported from shared libraries such as dynamic shared objects (DSO's) on + Unix-like systems or dynamic-link libraries (DLL's) on Windows. +
+
+ The Microsoft VC++ compiler has long supplied __declspec(dllexport) and __declspec(dllimport) extensions for this purpose, as do virtually
+ all other compilers targeting the Windows platform.
+
+ Modern versions of the GNU GCC compiler provide the __attribute__((visibility("default"))) extension to indicate that a symbol
+ should be exported. All other symbols may be hidden by using the -fvisibility-hidden
+ or -fvisibility-ms-compat compiler switches.
+
+ Boost supplies several macros to make it easier to manage symbol visibility + in a way that is portable between compilers and operating systems. +
+|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be exported from a shared library. If the compiler + has no such extension, the macro is defined with no replacement + text. + + |
+
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be imported from a shared library. If the compiler + has no such extension, the macro is defined with no replacement + text. + + |
+
|
+
+ |
+
+ + Defines the syntax of a C++ language extension that indicates + a symbol is to be globally visible. If the compiler has no such + extension, the macro is defined with no replacement text. Needed + for classes that are not otherwise exported, but are used by + RTTI. Examples include class for objects that will be thrown + as exceptions or used in dynamic_casts, across shared library + boundaries. For example, a header-only exception class might + look like this: + +class BOOST_SYMBOL_VISIBLE my_exception : public std::runtime_error { ... }; ++ + Without BOOST_SYMBOL_VISIBLE, it would be impossible to catch + my_exception thrown from a shared library compiled by GCC with + the -fvisibility=hidden option. + + |
+
|
+
+ |
+
+
+ The compiler has C++ extensions |
+
+ Typical usage: +
++ boost/foo/config.hpp +
+... +#if defined(BOOST_ALL_DYN_LINK) || defined(BOOST_FOO_DYN_LINK) +# if defined(BOOST_FOO_SOURCE) +# define BOOST_FOO_DECL BOOST_SYMBOL_EXPORT +# else +# define BOOST_FOO_DECL BOOST_SYMBOL_IMPORT +# endif +#else +# define BOOST_FOO_DECL +#endif +... ++
+ boost/foo/foo.hpp +
+#include <boost/foo/config.hpp> +... +class BOOST_FOO_DECL bar { ... }; +... +void BOOST_FOO_DECL f(); +... ++
+ boost/libs/foo/src/foo.cpp +
+#define BOOST_FOO_SOURCE +#include <boost/foo/foo.hpp> +... +void BOOST_FOO_DECL f() +{ + ... +} +... ++
+ When linking against a pre-compiled library it vital that the ABI used
+ by the compiler when building the library matches exactly
+ the ABI used by the code using the library. In this case ABI means things
+ like the struct packing arrangement used, the name mangling scheme used,
+ or the size of some types (enum types for example). This is separate from
+ things like threading support, or runtime library variations, which have
+ to be dealt with by build variants. To put this in perspective there is
+ one compiler (Borland's) that has so many compiler options that make subtle
+ changes to the ABI, that at least in theory there 3200 combinations, and
+ that's without considering runtime library variations. Fortunately these
+ variations can be managed by #pragma's
+ that tell the compiler what ABI to use for the types declared in your library.
+ In order to avoid sprinkling #pragma's
+ all over the boost headers, there are some prefix and suffix headers that
+ do the job. Typical usage is:
+
+ my_library.hpp +
+#ifndef MY_INCLUDE_GUARD +#define MY_INCLUDE_GUARD + +// all includes go here: ++#include <boost/config.hpp>+#include <whatever> + +#include <boost/config/abi_prefix.hpp>// must be the last #include + +namespace boost { + +// your code goes here + +} + +#include <boost/config/abi_suffix.hpp>// pops abi_prefix.hpp pragmas + +#endif // include guard +
+ my_library.cpp +
+... +// nothing special need be done in the implementation file +... ++
+ The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS,
+ or they can define BOOST_ABI_PREFIX
+ and/or BOOST_ABI_SUFFIX
+ to point to their own prefix/suffix headers if they so wish.
+
+ It is essential that users link to a build of a library which was built + against the same runtime library that their application will be built against + -if this does not happen then the library will not be binary compatible + with their own code- and there is a high likelihood that their application + will experience runtime crashes. These kinds of problems can be extremely + time consuming and difficult to debug, and often lead to frustrated users + and authors alike (simply selecting the right library to link against is + not as easy as it seems when their are 6-8 of them to chose from, and some + users seem to be blissfully unaware that there even are different runtimes + available to them). +
+
+ To solve this issue, some compilers allow source code to contain #pragma's that instruct the linker
+ which library to link against, all the user need do is include the headers
+ they need, place the compiled libraries in their library search path, and
+ the compiler and linker do the rest. Boost.config supports this via the
+ header <boost/config/auto_link.hpp>, before including this header one or
+ more of the following macros need to be defined:
+
+
BOOST_LIB_NAME+ Required: An identifier containing the basename of the library, for + example 'boost_regex'. +
BOOST_DYN_LINK+ Optional: when set link to dll rather than static library. +
BOOST_LIB_DIAGNOSTIC+ Optional: when set the header will print out the name of the library + selected (useful for debugging). +
+ If the compiler supports this mechanism, then it will be told to link against
+ the appropriately named library, the actual algorithm used to mangle the
+ name of the library is documented inside <boost/config/auto_link.hpp>
+ and has to match that used to create the libraries via bjam 's install
+ rules.
+
+ my_library.hpp +
+... +// +// Don't include auto-linking code if the user has disabled it by +// defining BOOST_ALL_NO_LIB, or BOOST_MY_LIBRARY_NO_LIB, or if this +// is one of our own source files (signified by BOOST_MY_LIBRARY_SOURCE): +// +#if !defined(BOOST_ALL_NO_LIB) && !defined(BOOST_MY_LIBRARY_NO_LIB) && !defined(BOOST_MY_LIBRARY_SOURCE) +# define BOOST_LIB_NAME boost_my_library +# ifdef BOOST_MY_LIBRARY_DYN_LINK +# define BOOST_DYN_LINK +# endif +# include <boost/config/auto_link.hpp> +#endif +... ++
+ my_library.cpp +
+// define BOOST_MY_LIBRARY_SOURCE so that the header knows that the +// library is being built (possibly exporting rather than importing code) +// +#define BOOST_MY_LIBRARY_SOURCE + +#include <boost/my_library/my_library.hpp> +... ++
| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ 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: +
+#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).
+ #include
+ <boost/config.hpp>" is the preferred way to obtain
+ configuration information not available from the standard headers such
+ as <climits>, etc.
+ <climits>, use those standard headers rather
+ than <boost/config.hpp>.
+ <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.
+ 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 header <boost/config/warning_disable.hpp>
+ can be used to disable certain compiler warnings that are hard or impossible
+ to otherwise remove.
+
+ Note that: +
++ Currently it disables the following warnings: +
+|
+ + Compiler + + |
+
+ + Warning + + |
+
|---|---|
|
+ + Visual C++ 8 and later + + |
+
+ + C4996: + Error 'function': was declared deprecated + + |
+
|
+ + Intel C++ + + |
+
+ + Warning 1786: relates to the use of "deprecated" standard + library functions rather like C4996 in Visual C++. + + |
+
+ When you need to add a new defect macro - either to fix a problem with an + existing library, or when adding a new library - distil the issue down to + a simple test case; often, at this point other (possibly better) workarounds + may become apparent. Secondly always post the test case code to the boost + mailing list and invite comments; remember that C++ is complex and that sometimes + what may appear a defect, may in fact turn out to be a problem with the authors + understanding of the standard. +
+
+ When you name the macro, follow the BOOST_NO_SOMETHING
+ naming convention, so that it's obvious that this is a macro reporting a
+ defect.
+
+ Finally, add the test program to the regression tests. You will need to place
+ the test case in a .ipp
+ file with the following comments near the top:
+
// MACRO: BOOST_NO_FOO +// TITLE: foo +// DESCRIPTION: If the compiler fails to support foo ++
+ These comments are processed by the autoconf script, so make sure the format
+ follows the one given. The file should be named "boost_no_foo.ipp",
+ where foo is the defect description - try and keep the file name under the
+ Mac 30 character filename limit though. You will also need to provide a function
+ prototype "int test()" that is declared in a namespace with
+ the same name as the macro, but in all lower case, and which returns zero
+ on success:
+
namespace boost_no_foo { +int test() +{ + // test code goes here: + // + return 0; +} + +} ++
+ Once the test code is in place in libs/config/test, updating the configuration + test system proceeds as: +
+libs/config/tools and run bjam.
+ This generates the .cpp
+ file test cases from the .ipp file, updates the libs/config/test/all/Jamfile.v2,
+ config_test.cpp and config_info.cpp.libs/config/test/all and run bjam
+ MACRONAME compiler-list,
+ where MACRONAME is the name of the new macro, and
+ compiler-list is a space separated
+ list of compilers to test with.**passed**.**passed**. If MACRONAME
+ is defined when it should not be defined, xxx_fail_test will not report
+ **passed**.libs/config/test and run bjam
+ config_info config_test
+ compiler-list.
+ config_info should build
+ and run cleanly for all the compilers in compiler-list
+ while config_test should
+ fail for those that have the defect, and pass for those that do not.
+ + Then you should: +
+
+ When you need to add a macro that describes a feature that the standard does
+ not require, follow the convention for adding a new defect macro (above),
+ but call the macro BOOST_HAS_FOO,
+ and name the test file "boost_has_foo.ipp".
+ Try not to add feature test macros unnecessarily, if there is a platform
+ specific macro that can already be used (for example _WIN32,
+ __BEOS__, or __linux) to identify the feature then use
+ that. Try to keep the macro to a feature group, or header name, rather than
+ one specific API (for example BOOST_HAS_NL_TYPES_H
+ rather than BOOST_HAS_CATOPEN).
+ If the macro describes a POSIX feature group, then add boilerplate code to
+ <boost/config/suffix.hpp>
+ to auto-detect the feature where possible (if you are wondering why we can't
+ use POSIX feature test macro directly, remember that many of these features
+ can be added by third party libraries, and are not therefore identified inside
+ <unistd.h>).
+
+ The aim of boost's configuration setup is that the configuration headers + should be relatively stable - a boost user should not have to recompile their + code just because the configuration for some compiler that they're not interested + in has changed. Separating the configuration into separate compiler/standard + library/platform sections provides for part of this stability, but boost + authors require some amount of restraint as well, in particular: +
++ <boost/config.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! +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
++ The problem with many traditional "textbook" implementations of configuration + headers (where all the configuration options are in a single "monolithic" + header) is that they violate certain fundamental software engineering principles + which would have the effect of making boost more fragile, more difficult to + maintain and more difficult to use safely. You can find a description of the + principles from the following + article. +
++ Consider a situation in which you are concurrently developing on multiple + platforms. Then consider adding a new platform or changing the platform definitions + of an existing platform. What happens? Everything, and this does literally + mean everything, recompiles. Isn't it quite absurd that adding a new platform, + which has absolutely nothing to do with previously existing platforms, means + that all code on all existing platforms needs to be recompiled? +
++ Effectively, there is an imposed physical dependency between platforms that + have nothing to do with each other. Essentially, the traditional solution + employed by configuration headers does not conform to the Open-Closed Principle: +
++ "A module should be open for extension but closed + for modification." +
+ Extending a traditional configuration header implies modifying existing code. +
++ Furthermore, consider the complexity and fragility of the platform detection + code. What if a simple change breaks the detection on some minor platform? + What if someone accidentally or on purpose (as a workaround for some other + problem) defines some platform dependent macros that are used by the detection + code? A traditional configuration header is one of the most volatile headers + of the entire library, and more stable elements of Boost would depend on + it. This violates the Stable Dependencies Principle: +
++ "Depend in the direction of stability." +
+ After even a minor change to a traditional configuration header on one minor + platform, almost everything on every platform should be tested if we follow + sound software engineering practice. +
+
+ Another important issue is that it is not always possible to submit changes
+ to <boost/config.hpp>.
+ Some boost users are currently working on platforms using tools and libraries
+ that are under strict Non-Disclosure Agreements. In this situation it is
+ impossible to submit changes to a traditional monolithic configuration header,
+ instead some method by which the user can insert their own configuration
+ code must be provided.
+
+ The approach taken by boost's configuration headers is to separate configuration + into three orthogonal parts: the compiler, the standard library and the platform. + Each compiler/standard library/platform gets its own mini-configuration header, + so that changes to one compiler's configuration (for example) does not affect + other compilers. In addition there are measures that can be taken both to + omit the compiler/standard library/platform detection code (so that adding + support to a new platform does not break dependencies), or to freeze the + configuration completely; providing almost complete protection against dependency + changes. +
+| + | + |
+ |
+Home | +Libraries | +People | +FAQ | +More | +
Copyright © 2001-2007 Beman Dawes, Vesa Karvonen, John + Maddock
+ Distributed under the Boost Software License, Version 1.0. (See accompanying + file LICENSE_1_0.txt or copy at http://www.boost.org/LICENSE_1_0.txt) +
+Table of Contents
++ Boost comes already configured for most common compilers and platforms; you + should be able to use boost "as is". Since the compiler is configured + separately from the standard library, the default configuration should work + even if you replace the compiler's standard library with a third-party standard + library (like STLport). +
++ Using boost "as is" without trying to reconfigure is the recommended + method for using boost. You can, however, run the configure script if you + want to, and there are regression tests provided that allow you to test the + current boost configuration with your particular compiler setup. +
++ Boost library users can request support for additional compilers or platforms + by visiting our Trac + and submitting a support request. +
++ Boost library implementations access configuration macros via +
+#include <boost/config.hpp> ++
+ While Boost library users are not required to include that file directly, + or use those configuration macros, such use is acceptable. The configuration + macros are documented as to their purpose, usage, and limitations which makes + them usable by both Boost library and user code. +
++ Boost informational or helper + macros are designed for use by Boost users as well as for our own internal + use. Note however, that the feature test + and defect test macros were designed + for internal use by Boost libraries, not user code, so they can change at + any time (though no gratuitous changes are made to them). Boost library problems + resulting from changes to the configuration macros are caught by the Boost + regression tests, so the Boost libraries are updated to account for those + changes. By contrast, Boost library user code can be adversely affected by + changes to the macros without warning. The best way to keep abreast of changes + to the macros used in user code is to monitor the discussions on the Boost + developers list. +
+ |
+Important | +
|---|---|
+ This configure script only sets up the Boost headers for use with a particular + compiler. It has no effect on Boost.Build, or how the libraries are built. + |
+ If you know that boost is incorrectly configured for your particular setup,
+ and you are on a UNIX like platform, then you may want to try and improve
+ things by running the boost configure script. From a shell command prompt
+ you will need to cd into <boost-root>/libs/config/
+ and type:
+
+
sh ./configure+
+ you will see a list of the items being checked as the script works its way + through the regression tests. Note that the configure script only really + auto-detects your compiler if it's called g++, c++ or CC. If you are using + some other compiler you will need to set one or more of the following environment + variables: +
+|
+ + Variable + + |
+
+ + Description + + |
+
|---|---|
|
+ + CXX + + |
+
+
+ The name of the compiler, for example |
+
|
+ + CXXFLAGS + + |
+
+
+ The compiler flags to use, for example |
+
|
+ + LDFLAGS + + |
+
+
+ The linker flags to use, for example |
+
|
+ + LIBS + + |
+
+
+ Any libraries to link in, for example |
+
+ For example to run the configure script with HP aCC, you might use something + like: +
+export CXX="aCC" +export CXXFLAGS="-Aa -DAportable -D__HPACC_THREAD_SAFE_RB_TREE \ + -DRWSTD_MULTI_THREAD -DRW_MULTI_THREAD -D_REENTRANT -D_THREAD_SAFE" +export LDFLAGS="-DAportable" +export LIBS="-lpthread" +sh ./configure ++
+ However you run the configure script, when it finishes you will find a new
+ header -user.hpp- located in the <boost-root>/libs/config/
+ directory. Note that configure does not install this
+ header into your boost include path by default. This header contains
+ all the options generated by the configure script, plus a header-section
+ that contains the user settable options from the default version of <boost/config/user.hpp>
+ (located under <boost-root>/boost/config/).
+ There are two ways you can use this header:
+
/boost/config/ so that it replaces the default user.hpp
+ provided by boost. This option allows only one configure-generated setup;
+ boost developers should avoid this option, as it incurs the danger of
+ accidentally committing a configure-modified <boost/config/user.hpp>
+ to the svn repository (something you will not be thanked for!).
+ BOOST_USER_CONFIG to point to it. For
+ example create a new sub-directory <boost-root>/boost/config/ user/, and copy the header there; for example
+ as multithread-gcc-config.hpp. Then, when compiling add the command
+ line option: -DBOOST_USER_CONFIG="<boost/config/user/multithread-gcc-config.hpp>",
+ and boost will use the new configuration header. This option allows you
+ to generate more than one configuration header, and to keep them separate
+ from the boost source - so that updates to the source do not interfere
+ with your configuration.
+
+ There are some configuration-options that represent user choices, rather
+ than compiler defects or platform specific options. These are listed in
+ <boost/config/user.hpp>
+ and at the start of a configure-generated user.hpp header.
+ You can define these on the command line, or by editing <boost/config/user.hpp>, they are listed in the following table:
+
|
+ + Macro + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+
+ When defined, it should point to the name of the user configuration
+ file to include prior to any boost configuration files. When not
+ defined, defaults to |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the compiler configuration
+ file to use. Defining this cuts out the compiler selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are using gcc, then you could define BOOST_COMPILER_CONFIG
+ to |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the standard library
+ configuration file to use. Defining this cuts out the standard
+ library selection logic, and eliminates the dependency on the header
+ containing that logic. For example if you are using STLport, then
+ you could define |
+
|
+
+ |
+
+
+ When defined, it should point to the name of the platform configuration
+ file to use. Defining this cuts out the platform selection logic,
+ and eliminates the dependency on the header containing that logic.
+ For example if you are compiling on linux, then you could define
+ |
+
|
+
+ |
+
+
+ When defined, no compiler configuration file is selected or included,
+ define when the compiler is fully conformant with the standard,
+ or where the user header (see |
+
|
+
+ |
+
+
+ When defined, no standard library configuration file is selected
+ or included, define when the standard library is fully conformant
+ with the standard, or where the user header (see |
+
|
+
+ |
+
+
+ When defined, no platform configuration file is selected or included,
+ define when the platform is fully conformant with the standard
+ (and has no useful extra features), or where the user header (see
+ |
+
|
+
+ |
+
+
+ Equivalent to defining all of |
+
|
+
+ |
+
+ + The normal behavior for compiler versions that are newer than the + last known version, is to assume that they have all the same defects + as the last known version. By setting this define, then compiler + versions that are newer than the last known version are assumed + to be fully conforming with the standard. This is probably most + useful for boost developers or testers, and for those who want + to use boost to test beta compiler versions. + + |
+
|
+
+ |
+
+ + When this flag is set, if the config finds anything unknown, then + it will stop with a #error rather than continue. Boost regression + testers should set this define, as should anyone who wants to quickly + check whether boost is supported on their platform. + + |
+
|
+
+ |
+
+ + When defined, disables threading support, even if the compiler + in its current translation mode supports multiple threads. + + |
+
|
+
+ |
+
+
+ When defined, disables the use of Win32 specific API's, even when
+ these are available. Also has the effect of setting |
+
|
+
+ |
+
+ + Stops boost headers from including any prefix/suffix headers that + normally control things like struct packing and alignment. + + |
+
|
+
+ |
+
+ + A prefix header to include in place of whatever boost.config would + normally select, any replacement should set up struct packing and + alignment options as required. + + |
+
|
+
+ |
+
+ + A suffix header to include in place of whatever boost.config would + normally select, any replacement should undo the effects of the + prefix header. + + |
+
|
+
+ |
+
+
+ Forces all libraries that have separate source, to be linked as
+ dll's rather than static libraries on Microsoft Windows (this macro
+ is used to turn on |
+
|
+
+ |
+
+
+ Forces library "whatever" to be linked as a dll rather
+ than a static library on Microsoft Windows: replace the WHATEVER
+ part of the macro name with the name of the library that you want
+ to dynamically link to, for example use |
+
|
+
+ |
+
+ + Tells the config system not to automatically select which libraries + to link against. Normally if a compiler supports #pragma lib, then + the correct library build variant will be automatically selected + and linked against, simply by the act of including one of that + library's headers. This macro turns that feature off. + + |
+
|
+
+ |
+
+
+ Tells the config system not to automatically select which library
+ to link against for library "whatever", replace WHATEVER
+ in the macro name with the name of the library; for example |
+
|
+
+ |
+
+ + Causes the auto-linking code to output diagnostic messages indicating + the name of the library that is selected for linking. + + |
+
|
+
+ |
+
+ + Overrides the name of the toolset part of the name of library being + linked to; note if defined this must be defined to a quoted string + literal, for example "abc". + + |
+
+ By setting various macros on the compiler command line or by editing <boost/config/user.hpp>, + the boost configuration setup can be optimised in a variety of ways. +
+
+ Boost's configuration is structured so that the user-configuration is included
+ first (defaulting to <boost/config/user.hpp>
+ if BOOST_USER_CONFIG is not
+ defined). This sets up any user-defined policies, and gives the user-configuration
+ a chance to influence what happens next.
+
+ Next the compiler, standard library, and platform configuration files are
+ included. These are included via macros (BOOST_COMPILER_CONFIG
+ etc, see user settable macros),
+ and if the corresponding macro is undefined then a separate header that detects
+ which compiler/standard library/platform is in use is included in order to
+ set these. The config can be told to ignore these headers altogether if the
+ corresponding BOOST_NO_XXX
+ macro is set (for example BOOST_NO_COMPILER_CONFIG
+ to disable including any compiler configuration file - see
+ user settable macros).
+
+ Finally the boost configuration header, includes <boost/config/suffix.hpp>; + this header contains any boiler plate configuration code - for example where + one boost macro being set implies that another must be set also. +
++ The following usage examples represent just a few of the possibilities: +
+
+ Lets suppose that we're building boost with Visual C++ 6, and STLport 4.0.
+ Lets suppose also that we don't intend to update our compiler or standard
+ library any time soon. In order to avoid breaking dependencies when we
+ update boost, we may want to "freeze" our configuration headers,
+ so that we only have to rebuild our project if the boost code itself has
+ changed, and not because the boost config has been updated for more recent
+ versions of Visual C++ or STLport. We'll start by realising that the configuration
+ files in use are: <boost/config/compiler/visualc.hpp> for the compiler, <boost/config/stdlib/stlport.hpp> for the standard library, and
+ <boost/config/platform/win32.hpp> for the platform. Next we'll
+ create our own private configuration directory: boost/config/mysetup/, and copy the configuration files into
+ there. Finally, open up <boost/config/user.hpp>
+ and edit the following defines:
+
#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. +
+
+ 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.
+
+ If you are working on a unix-like platform then you can use the configure + script to generate a "frozen" configuration based on your current + compiler setup - see using the configure + script for more details. +
+
+ The boost configuration library provides a full set of regression test programs
+ under the <boost-root>/boost/config/
+ test/
+ sub-directory:
+
|
+ + File + + |
+
+ + Description + + |
+
|---|---|
|
+
+ |
+
+ + Prints out a detailed description of your compiler/standard library/platform + setup, plus your current boost configuration. The information provided + by this program useful in setting up the boost configuration files. + If you report that boost is incorrectly configured for your compiler/library/platform + then please include the output from this program when reporting + the changes required. + + |
+
|
+
+ |
+
+ + A monolithic test program that includes most of the individual + test cases. This provides a quick check to see if boost is correctly + configured for your compiler/library/platform. + + |
+
|
+
+ |
+
+
+ Tests your standard library's |
+
|
+
+ |
+
+
+ Individual compiler defect test files. Each of these should compile,
+ if one does not then the corresponding |
+
|
+
+ |
+
+
+ Individual compiler defect test files. Each of these should not
+ compile, if one does then the corresponding |
+
|
+
+ |
+
+
+ Individual feature test files. If one of these does not compile
+ then the corresponding |
+
|
+
+ |
+
+
+ Individual feature test files. If one of these does compile then
+ the corresponding |
+
+ Although you can run the configuration regression tests as individual test + files, there are rather a lot of them, so there are a couple of shortcuts + to help you out: +
++ If you have built the boost + regression test driver, then you can use this to produce a nice html + formatted report of the results using the supplied test file. +
++ Alternatively you can run the configure script like this: +
++
./configure + --enable-test+
+ in which case the script will test the current configuration rather than + creating a new one from scratch. +
+
+ If you are reporting the results of these tests for a new platform/library/compiler
+ then please include a log of the full compiler output, the output from config_info.cpp, and the pass/fail test results.
+
Last revised: November 20, 2012 at 20:33:30 GMT |
++ |