Boost Macro Reference

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
`BOOST_BCB_PARTIAL_SPECIALIZATION_BUG`	Compiler	The compiler exibits certain partial specialisation bug - probably Borland C++ Builder specific.
`BOOST_FUNCTION_SCOPE_USING_DECLARATION_BREAKS_ADL`	Compiler	Argument dependent lookup fails if there is a using declaration for the symbol being looked up in the current scope. For example, using `boost::get_pointer`; prevents ADL from finding overloads of `get_pointer` in namespaces nested inside boost (but not elsewhere). Probably Borland specific.
`BOOST_NO_ADL_BARRIER`	Compiler	The compiler locates and searches namespaces that it should not in fact search when performing argument dependent lookup.
`BOOST_NO_ARGUMENT_DEPENDENT_LOOKUP`	Compiler	Compiler does not implement argument-dependent lookup (also named Koenig lookup); see std::3.4.2 [basic.koenig.lookup]
`BOOST_NO_AUTO_PTR`	Standard library	If the compiler / library supplies non-standard or broken `std::auto_ptr`.
`BOOST_NO_COMPLETE_VALUE_INITIALIZATION`	Compiler	Compiler has not completely implemented value-initialization. See also The Utility/Value Init docs
`BOOST_NO_CTYPE_FUNCTIONS`	Platform	The Platform does not provide functions for the character-classifying operations `<ctype.h>` and `<cctype>`, only macros.
`BOOST_NO_CV_SPECIALIZATIONS`	Compiler	If template specialisations for cv-qualified types conflict with a specialisation for a cv-unqualififed type.
`BOOST_NO_CV_VOID_SPECIALIZATIONS`	Compiler	If template specialisations for cv-void types conflict with a specialisation for void.
`BOOST_NO_CWCHAR`	Platform	The Platform does not provide `<wchar.h>` and `<cwchar>`.
`BOOST_NO_CWCTYPE`	Platform	The Platform does not provide `<wctype.h>` and `<cwctype>`.
`BOOST_NO_FENV_H`	Platform, Standard library	The C standard library doesn't provide `<fenv.h>`. `<boost/detail/fenv.hpp>` should be included instead of `<fenv.h>` for maximum portability on platforms which do provide `<fenv.h>`.
`BOOST_NO_DEPENDENT_NESTED_DERIVATIONS`	Compiler	The compiler fails to compile a nested class that has a dependent base class: template<typename T> struct foo : { template<typename U> struct bar : public U {}; };
`BOOST_NO_DEPENDENT_TYPES_IN_TEMPLATE_VALUE_PARAMETERS`	Compiler	Template value parameters cannot have a dependent type, for example: template<class T, typename T::type value> class X { ... };
`BOOST_NO_EXCEPTION_STD_NAMESPACE`	Standard Library	The standard library does not put some or all of the contents of `<exception>` in namespace std.
`BOOST_NO_EXCEPTIONS`	Compiler	The compiler does not support exception handling (this setting is typically required by many C++ compilers for embedded platforms). Note that there is no requirement for boost libraries to honor this configuration setting - indeed doing so may be impossible in some cases. Those libraries that do honor this will typically abort if a critical error occurs - you have been warned!
`BOOST_NO_EXPLICIT_FUNCTION_TEMPLATE_ARGUMENTS`	Compiler	Can only use deduced template arguments when calling function template instantiations.
`BOOST_NO_FUNCTION_TEMPLATE_ORDERING`	Compiler	The compiler does not perform function template ordering or its function template ordering is incorrect. // #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.
`BOOST_NO_INCLASS_MEMBER_INITIALIZATION`	Compiler	Compiler violates std::9.4.2/4.
`BOOST_NO_INTRINSIC_WCHAR_T`	Compiler	The C++ implementation does not provide `wchar_t`, or it is really a synonym for another integral type. Use this symbol to decide whether it is appropriate to explicitly specialize a template on `wchar_t` if there is already a specialization for other integer types.
`BOOST_NO_IOSFWD`	std lib	The standard library lacks `<iosfwd>`.
`BOOST_NO_IOSTREAM`	std lib	The standard library lacks `<iostream>`, `<istream>` or `<ostream>`.
`BOOST_NO_IS_ABSTRACT`	Compiler	The C++ compiler does not support SFINAE with abstract types, this is covered by Core Language DR337, but is not part of the current standard. Fortunately most compilers that support SFINAE also support this DR.
`BOOST_NO_LIMITS`	Standard library	The C++ implementation does not provide the `<limits>` header. Never check for this symbol in library code; always include `<boost/limits.hpp>`, which guarantees to provide `std::numeric_limits`.
`BOOST_NO_NUMERIC_LIMITS_LOWEST`	Standard library	Static function `numeric_limits<T>::lowest()` is not available for use.
`BOOST_NO_LIMITS_COMPILE_TIME_CONSTANTS`	Standard library	Constants such as `numeric_limits<T>::is_signed` are not available for use at compile-time.
`BOOST_NO_LONG_LONG_NUMERIC_LIMITS`	Standard library	There is no specialization for `numeric_limits<long long>` and `numeric_limits<unsigned long long>`. `<boost/limits.hpp>` will then add these specializations as a standard library "fix" only if the compiler supports the `long long` datatype.
`BOOST_NO_MEMBER_FUNCTION_SPECIALIZATIONS`	Compiler	The compiler does not support the specialization of individual member functions of template classes.
`BOOST_NO_MEMBER_TEMPLATE_KEYWORD`	Compiler	If the compiler supports member templates, but not the template keyword when accessing member template classes.
`BOOST_NO_MEMBER_TEMPLATE_FRIENDS`	Compiler	Member template friend syntax (`template<class P> friend class frd;`) described in the C++ Standard, 14.5.3, not supported.
`BOOST_NO_MEMBER_TEMPLATES`	Compiler	Member template functions not fully supported.
`BOOST_NO_MS_INT64_NUMERIC_LIMITS`	Standard library	There is no specialization for `numeric_limits<__int64>` and `numeric_limits<unsigned __int64>`. `<boost/limits.hpp>` will then add these specializations as a standard library "fix", only if the compiler supports the `__int64` datatype.
`BOOST_NO_NESTED_FRIENDSHIP`	Compiler	Compiler doesn't allow a nested class to access private members of its containing class. Probably Borland/CodeGear specific.
`BOOST_NO_OPERATORS_IN_NAMESPACE`	Compiler	Compiler requires inherited operator friend functions to be defined at namespace scope, then using'ed to boost. Probably GCC specific. See `<boost/operators.hpp>` for example.
`BOOST_NO_PARTIAL_SPECIALIZATION_IMPLICIT_DEFAULT_ARGS`	Compiler	The compiler does not correctly handle partial specializations which depend upon default arguments in the primary template.
`BOOST_NO_POINTER_TO_MEMBER_CONST`	Compiler	The compiler does not correctly handle pointers to const member functions, preventing use of these in overloaded function templates. See `<boost/functional.hpp>` for example.
`BOOST_NO_POINTER_TO_MEMBER_TEMPLATE_PARAMETERS`	Compiler	Pointers to members don't work when used as template parameters.
`BOOST_NO_PRIVATE_IN_AGGREGATE`	Compiler	The compiler misreads 8.5.1, treating classes as non-aggregate if they contain private or protected member functions.
`BOOST_NO_RTTI`	Compiler	The compiler may (or may not) have the typeid operator, but RTTI on the dynamic type of an object is not supported.
`BOOST_NO_SFINAE`	Compiler	The compiler does not support the "Substitution Failure Is Not An Error" meta-programming idiom.
`BOOST_NO_SFINAE_EXPR`	Compiler	The compiler does not support usage of SFINAE with arbitrary expressions.
`BOOST_NO_STD_ALLOCATOR`	Standard library	The C++ standard library does not provide a standards conforming `std::allocator`.
`BOOST_NO_STD_DISTANCE`	Standard library	The platform does not have a conforming version of `std::distance`.
`BOOST_NO_STD_ITERATOR`	Standard library	The C++ implementation fails to provide the `std::iterator` class.
`BOOST_NO_STD_ITERATOR_TRAITS`	Standard library	The compiler does not provide a standard compliant implementation of `std::iterator_traits`. Note that the compiler may still have a non-standard implementation.
`BOOST_NO_STD_LOCALE`	Standard library	The standard library lacks `std::locale`.
`BOOST_NO_STD_MESSAGES`	Standard library	The standard library lacks a conforming `std::messages` facet.
`BOOST_NO_STD_MIN_MAX`	Standard library	The C++ standard library does not provide the `min()` and `max()` template functions that should be in `<algorithm>`.
`BOOST_NO_STD_OUTPUT_ITERATOR_ASSIGN`	Standard library	Defined if the standard library's output iterators are not assignable.
`BOOST_NO_STD_TYPEINFO`	Standard library	The <typeinfo> header declares `type_info` in the global namespace instead of namespace std.
`BOOST_NO_STD_USE_FACET`	Standard library	The standard library lacks a conforming `std::use_facet`.
`BOOST_NO_STD_WSTREAMBUF`	Standard library	The standard library's implementation of `std::basic_streambuf<wchar_t>` is either missing, incomplete, or buggy.
`BOOST_NO_STD_WSTRING`	Standard library	The standard library lacks `std::wstring`.
`BOOST_NO_STDC_NAMESPACE`	Compiler, Platform	The contents of C++ standard headers for C library functions (the `<c...>` headers) have not been placed in namespace std. This test is difficult - some libraries "fake" the std C functions by adding using declarations to import them into namespace std, unfortunately they don't necessarily catch all of them...
`BOOST_NO_STRINGSTREAM`	Standard library	The C++ implementation does not provide the `<sstream>` header.
`BOOST_NO_SWPRINTF`	Platform	The platform does not have a conforming version of `swprintf`.
`BOOST_NO_TEMPLATE_PARTIAL_SPECIALIZATION`	Compiler	Class template partial specialization (14.5.4 [temp.class.spec]) not supported.
`BOOST_NO_TEMPLATED_IOSTREAMS`	Standard library	The standard library does not provide templated iostream classes.
`BOOST_NO_TEMPLATED_ITERATOR_CONSTRUCTORS`	Standard library	The standard library does not provide templated iterator constructors for its containers.
`BOOST_NO_TEMPLATE_TEMPLATES`	Compiler	The compiler does not support template template parameters.
`BOOST_NO_TYPEID`	Compiler	The compiler does not support the typeid operator at all.
`BOOST_NO_TYPENAME_WITH_CTOR`	Compiler	The typename keyword cannot be used when creating a temporary of a Dependent type.
`BOOST_NO_UNREACHABLE_RETURN_DETECTION`	Compiler	If a return is unreachable, then no return statement should be required, however some compilers insist on it, while other issue a bunch of warnings if it is in fact present.
`BOOST_NO_USING_DECLARATION_OVERLOADS_FROM_TYPENAME_BASE`	Compiler	The compiler will not accept a using declaration that brings a function from a typename used as a base class into a derived class if functions of the same name are present in the derived class.
`BOOST_NO_USING_TEMPLATE`	Compiler	The compiler will not accept a using declaration that imports a template class or function from another namespace. Originally a Borland specific problem with imports to/from the global namespace, extended to MSVC6 which has a specific issue with importing template classes (but not functions).
`BOOST_NO_VOID_RETURNS`	Compiler	The compiler does not allow a void function to return the result of calling another void function. void f() {} void g() { return f(); }

Macros that describe optional features

The following macros describe features that are not required by the C++ standard. The macro is only defined if the feature is present.

Macro	Section	Description
`BOOST_HAS_BETHREADS`	Platform	The platform supports BeOS style threads.
`BOOST_HAS_CLOCK_GETTIME`	Platform	The platform has the POSIX API `clock_gettime`.
`BOOST_HAS_DIRENT_H`	Platform	The platform has the POSIX header `<dirent.h>`.
`BOOST_HAS_EXPM1`	Platform	The platform has the functions `expm1`, `expm1f` and `expm1l` in `<math.h>`
`BOOST_HAS_FTIME`	Platform	The platform has the Win32 API type FTIME.
`BOOST_HAS_GETSYSTEMTIMEASFILETIME`	Platform	The platform has the Win32 API GetSystemTimeAsFileTime.
`BOOST_HAS_GETTIMEOFDAY`	Platform	The platform has the POSIX API `gettimeofday`.
`BOOST_HAS_HASH`	Standard library	The C++ implementation provides the (SGI) hash_set and hash_map classes. When defined, `BOOST_HASH_SET_HEADER` and `BOOST_HASH_LIST_HEADER` will contain the names of the header needed to access hash_set and hash_map; `BOOST_STD_EXTENSION_NAMESPACE` will provide the namespace in which the two class templates reside.
`BOOST_HAS_LOG1P`	Platform	The platform has the functions `log1p`, `log1pf` and `log1pl` in `<math.h>`.
`BOOST_HAS_MACRO_USE_FACET`	Standard library	The standard library lacks a conforming `std::use_facet`, but has a macro `_USE(loc, Type)` that does the job. This is primarily for the Dinkumware std lib.
`BOOST_HAS_MS_INT64`	Compiler	The compiler supports the `__int64` data type.
`BOOST_HAS_NANOSLEEP`	Platform	The platform has the POSIX API nanosleep.
`BOOST_HAS_NL_TYPES_H`	Platform	The platform has an `<nl_types.h>`.
`BOOST_HAS_NRVO`	Compiler	Indicated that the compiler supports the named return value optimization (NRVO). Used to select the most efficient implementation for some function. See `<boost/operators.hpp>` for example.
`BOOST_HAS_PARTIAL_STD_ALLOCATOR`	Standard Library	The standard library has a partially conforming `std::allocator` class, but without any of the member templates.
`BOOST_HAS_PTHREAD_DELAY_NP`	Platform	The platform has the POSIX API `pthread_delay_np`.
`BOOST_HAS_PTHREAD_MUTEXATTR_SETTYPE`	Platform	The platform has the POSIX API `pthread_mutexattr_settype`.
`BOOST_HAS_PTHREAD_YIELD`	Platform	The platform has the POSIX API `pthread_yield`.
`BOOST_HAS_PTHREADS`	Platform	The platform support POSIX style threads.
`BOOST_HAS_SCHED_YIELD`	Platform	The platform has the POSIX API `sched_yield`.
`BOOST_HAS_SGI_TYPE_TRAITS`	Compiler, Standard library	The compiler has native support for SGI style type traits.
`BOOST_HAS_STDINT_H`	Platform	The platform has a `<stdint.h>`
`BOOST_HAS_SLIST`	Standard library	The C++ implementation provides the (SGI) slist class. When defined, `BOOST_SLIST_HEADER` will contain the name of the header needed to access `slist` and `BOOST_STD_EXTENSION_NAMESPACE` will provide the namespace in which `slist` resides.
`BOOST_HAS_STLP_USE_FACET`	Standard library	The standard library lacks a conforming `std::use_facet`, but has a workaround class-version that does the job. This is primarily for the STLport std lib.
`BOOST_HAS_TR1_ARRAY`	Standard library	The library has a TR1 conforming version of `<array>`.
`BOOST_HAS_TR1_COMPLEX_OVERLOADS`	Standard library	The library has a version of `<complex>` that supports passing scalars to the complex number algorithms.
`BOOST_HAS_TR1_COMPLEX_INVERSE_TRIG`	Standard library	The library has a version of `<complex>` that includes the new inverse trig functions from TR1.
`BOOST_HAS_TR1_REFERENCE_WRAPPER`	Standard library	The library has TR1 conforming reference wrappers in `<functional>`.
`BOOST_HAS_TR1_RESULT_OF`	Standard library	The library has a TR1 conforming result_of template in `<functional>`.
`BOOST_HAS_TR1_MEM_FN`	Standard library	The library has a TR1 conforming mem_fn function template in `<functional>`.
`BOOST_HAS_TR1_BIND`	Standard library	The library has a TR1 conforming bind function template in `<functional>`.
`BOOST_HAS_TR1_FUNCTION`	Standard library	The library has a TR1 conforming function class template in `<functional>`.
`BOOST_HAS_TR1_HASH`	Standard library	The library has a TR1 conforming hash function template in `<functional>`.
`BOOST_HAS_TR1_SHARED_PTR`	Standard library	The library has a TR1 conforming `shared_ptr` class template in `<memory>`.
`BOOST_HAS_TR1_RANDOM`	Standard library	The library has a TR1 conforming version of `<random>`.
`BOOST_HAS_TR1_REGEX`	Standard library	The library has a TR1 conforming version of `<regex>`.
`BOOST_HAS_TR1_TUPLE`	Standard library	The library has a TR1 conforming version of `<tuple>`.
`BOOST_HAS_TR1_TYPE_TRAITS`	Standard library	The library has a TR1 conforming version of `<type_traits>`.
`BOOST_HAS_TR1_UTILITY`	Standard library	The library has the TR1 additions to `<utility>` (tuple interface to `std::pair`).
`BOOST_HAS_TR1_UNORDERED_MAP`	Standard library	The library has a TR1 conforming version of `<unordered_map>`.
`BOOST_HAS_TR1_UNORDERED_SET`	Standard library	The library has a TR1 conforming version of `<unordered_set>`.
`BOOST_HAS_TR1`	Standard library	Implies all the other `BOOST_HAS_TR1_*` macros should be set.
`BOOST_HAS_THREADS`	Platform, Compiler	Defined if the compiler, in its current translation mode, supports multiple threads of execution.
`BOOST_HAS_TWO_ARG_USE_FACET`	Standard library	The standard library lacks a conforming std::use_facet, but has a two argument version that does the job. This is primarily for the Rogue Wave std lib.
`BOOST_HAS_UNISTD_H`	Platform	The Platform provides `<unistd.h>`.
`BOOST_HAS_WINTHREADS`	Platform	The platform supports MS Windows style threads.
`BOOST_MSVC_STD_ITERATOR`	Standard library	Microsoft's broken version of `std::iterator` is being used. This implies that `std::iterator` takes no more than two template parameters.
`BOOST_MSVC6_MEMBER_TEMPLATES`	Compiler	Microsoft Visual C++ 6.0 has enough member template idiosyncrasies (being polite) that `BOOST_NO_MEMBER_TEMPLATES` is defined for this compiler. `BOOST_MSVC6_MEMBER_TEMPLATES` is defined to allow compiler specific workarounds. This macro gets defined automatically if `BOOST_NO_MEMBER_TEMPLATES` is not defined - in other words this is treated as a strict subset of the features required by the standard.
`BOOST_HAS_STDINT_H`	Platform	There are no 1998 C++ Standard headers `<stdint.h>` or `<cstdint>`, although the 1999 C Standard does include `<stdint.h>`. If `<stdint.h>` is present, `<boost/stdint.h>` can make good use of it, so a flag is supplied (signalling presence; thus the default is not present, conforming to the current C++ standard).

Macros that describe possible C++ future features

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
`BOOST_HAS_CONCEPTS`	The compiler supports concepts.

Macros that describe C++11 features not supported

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
`BOOST_NO_0X_HDR_ARRAY`	The standard library does not provide header <array>.
`BOOST_NO_0X_HDR_CHRONO`	The standard library does not provide header <chrono>.
`BOOST_NO_0X_HDR_CODECVT`	The standard library does not provide header <codecvt>.
`BOOST_NO_0X_HDR_CONDITION_VARIABLE`	The standard library does not provide header <condition_variable>.
`BOOST_NO_0X_HDR_FORWARD_LIST`	The standard library does not provide header <forward_list>.
`BOOST_NO_0X_HDR_FUTURE`	The standard library does not provide header <future>.
`BOOST_NO_0X_HDR_INITIALIZER_LIST`	The standard library does not provide header <initializer_list>.
`BOOST_NO_0X_HDR_MUTEX`	The standard library does not provide header <mutex>.
`BOOST_NO_0X_HDR_RANDOM`	The standard library does not provide header <random>.
`BOOST_NO_0X_HDR_RATIO`	The standard library does not provide header <ratio>.
`BOOST_NO_0X_HDR_REGEX`	The standard library does not provide header <regex>.
`BOOST_NO_0X_HDR_SYSTEM_ERROR`	The standard library does not provide header <system_error>.
`BOOST_NO_0X_HDR_THREAD`	The standard library does not provide header <thread>.
`BOOST_NO_0X_HDR_TUPLE`	The standard library does not provide header <tuple>.
`BOOST_NO_0X_HDR_TYPEINDEX`	The standard library does not provide header <typeindex>.
`BOOST_NO_0X_HDR_TYPE_TRAITS`	The standard library does not provide header <type_traits>.
`BOOST_NO_0X_HDR_UNORDERED_MAP`	The standard library does not provide header <unordered_map>.
`BOOST_NO_0X_HDR_UNORDERED_SET`	The standard library does not provide header <unordered_set>.
`BOOST_NO_AUTO_DECLARATIONS`	The compiler does not support type deduction for variables declared with the `auto` keyword (`auto var = ...;`).
`BOOST_NO_AUTO_MULTIDECLARATIONS`	The compiler does not support type deduction for multiple variables declared with the `auto` keyword (`auto var = ..., *ptr = ...;`).
`BOOST_NO_CHAR16_T`	The compiler does not support type `char16_t`.
`BOOST_NO_CHAR32_T`	The compiler does not support type `char32_t`.
`BOOST_NO_TEMPLATE_ALIASES`	The compiler does not support template aliases.
`BOOST_NO_CONSTEXPR`	The compiler does not support `constexpr`.
`BOOST_NO_DECLTYPE`	The compiler does not support `decltype`.
`BOOST_NO_DECLTYPE_N3276`	The compiler does not support the extension to `decltype` described in N3276, accepted in Madrid, March 2011.
`BOOST_NO_DEFAULTED_FUNCTIONS`	The compiler does not support defaulted (`= default`) functions.
`BOOST_NO_DELETED_FUNCTIONS`	The compiler does not support deleted (`= delete`) functions.
`BOOST_NO_EXPLICIT_CONVERSION_OPERATORS`	The compiler does not support explicit conversion operators (`explicit operator T()`).
`BOOST_NO_EXTERN_TEMPLATE`	The compiler does not support explicit instantiation forward declarations for templates (`extern template ...`).
`BOOST_NO_FUNCTION_TEMPLATE_DEFAULT_ARGS`	The compiler does not support default template arguments for function templates.
`BOOST_NO_INITIALIZER_LISTS`	The C++ compiler does not support C++0x initializer lists.
`BOOST_NO_LAMBDAS`	The compiler does not support Lambdas.
`BOOST_NO_LONG_LONG`	The compiler does not support `long long`.
`BOOST_NO_NOEXCEPT`	The compiler does not support `noexcept`.
`BOOST_NO_NULLPTR`	The compiler does not support `nullptr`.
`BOOST_NO_RAW_LITERALS`	The compiler does not support raw string literals.
`BOOST_NO_RVALUE_REFERENCES`	The compiler does not support r-value references.
`BOOST_NO_SCOPED_ENUMS`	The compiler does not support scoped enumerations (`enum class`).
`BOOST_NO_STATIC_ASSERT`	The compiler does not support `static_assert`.
`BOOST_NO_STD_UNORDERD`	The standard library does not support <unordered_map> and <unordered_set>.
`BOOST_NO_TEMPLATE_ALIASES`	The compiler does not support template aliases.
`BOOST_NO_UNICODE_LITERALS`	The compiler does not support Unicode (`u8`, `u`, `U`) literals.
`BOOST_NO_UNIFIED_INITIALIZATION_SYNTAX`	The compiler does not support the C++11 Unified Initialization Syntax.
`BOOST_NO_VARIADIC_TEMPLATES`	The compiler does not support variadic templates.
`BOOST_NO_VARIADIC_MACROS`	The compiler does not support variadic macros.

Macros that allow use of C++11 features with C++03 compilers

The following macros allow use of C++11 features even with compilers that do not yet provide compliant C++11 support.

Macro	Section	Description
`BOOST_CONSTEXPR`	Some compilers don't support the use of `constexpr`. This macro expands to nothing on those compilers, and `constexpr` elsewhere. For example, when defining a constexpr function or constructor replace: constexpr tuple(); with: BOOST_CONSTEXPR tuple();
`BOOST_CONSTEXPR_OR_CONST`	Some compilers don't support the use of `constexpr`. This macro expands to `const` on those compilers, and `constexpr` elsewhere. For example, when defining const expr variables replace: static constexpr UIntType xor_mask = a; with: static BOOST_CONSTEXPR_OR_CONST UIntType xor_mask = a;
`BOOST_STATIC_CONSTEXPR`	This is a shortcut for `static BOOST_CONSTEXPR_OR_CONST`For example, when defining const expr variables replace: 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 `BOOST_NO_NOEXCEPT` is defined (i.e. C++03 compliant compilers) these macros are defined as: #define BOOST_NOEXCEPT #define BOOST_NOEXCEPT_IF(Predicate) #define BOOST_NOEXCEPT_EXPR(Expression) false If `BOOST_NO_NOEXCEPT` is not defined (i.e. C++11 compliant compilers) they are defined as: #define BOOST_NOEXCEPT noexcept #define BOOST_NOEXCEPT_IF(Predicate) noexcept((Predicate)) #define BOOST_NOEXCEPT_EXPR(Expression) noexcept((Expression))

Boost Helper Macros

The following macros are either simple helpers, or macros that provide workarounds for compiler/standard library defects.

Macro	Description
`BOOST_WORKAROUND`	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 `MACRONAME` is a macro that usually describes the version number to be tested against, and `CONDITION` is a comparison operator followed by a value. For example `BOOST_WORKAROUND(BOOST_INTEL, <= 1010)` would evaluate to `1` for Intel C++ 10.1 and earlier. The macro can also be used with `BOOST_TESTED_AT` if all current compiler versions exhibit the issue, but the issue is expected to be fixed at some later point. For example `BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x590))` would normally evaluate to `1` for all values of `__BORLANDC__` unless the macro `BOOST_DETECT_OUTDATED_WORKAROUNDS` is defined, in which case evaluates to `(__BORLANDC__ <= 0x590)`. Note: the ultimate source of documentation for this macro is in boost/detail/workaround.hpp.
`BOOST_PREVENT_MACRO_SUBSTITUTION`	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);
`BOOST_DEDUCED_TYPENAME`	Some compilers don't support the use of typename for dependent types in deduced contexts. This macro expands to nothing on those compilers, and typename elsewhere. For example, replace: `template <class T> void f(T, typename T::type);` with: `template <class T> void f(T, BOOST_DEDUCED_TYPENAME T::type);`
`BOOST_HASH_MAP_HEADER`	The header to include to get the SGI `hash_map` class. This macro is only available if `BOOST_HAS_HASH` is defined.
`BOOST_HASH_SET_HEADER`	The header to include to get the SGI `hash_set` class. This macro is only available if `BOOST_HAS_HASH` is defined.
`BOOST_SLIST_HEADER`	The header to include to get the SGI `slist` class. This macro is only available if `BOOST_HAS_SLIST` is defined.
`BOOST_STD_EXTENSION_NAMESPACE`	The namespace used for std library extensions (hashtable classes etc).
`BOOST_STATIC_CONSTANT(Type, assignment)`	On compilers which don't allow in-class initialization of static integral constant members, we must use enums as a workaround if we want the constants to be available at compile-time. This macro gives us a convenient way to declare such constants. For example instead of: struct foo{ static const int value = 2; }; use: struct foo{ BOOST_STATIC_CONSTANT(int, value = 2); };
`BOOST_UNREACHABLE_RETURN(result)`	Normally evaluates to nothing, but evaluates to return x; if the compiler requires a return, even when it can never be reached.
`BOOST_EXPLICIT_TEMPLATE_TYPE(t)` `BOOST_EXPLICIT_TEMPLATE_NON_TYPE(t,v)` `BOOST_APPEND_EXPLICIT_TEMPLATE_TYPE(t)` `BOOST_APPEND_EXPLICIT_TEMPLATE_NON_TYPE(t,v)`	Some compilers silently "fold" different function template instantiations if some of the template parameters don't appear in the function parameter list. For instance: #include <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 `2 2 double double` on VC++ 6. These macros, to be used in the function parameter list, fix the problem without effects on the calling syntax. For instance, in the case above write: template <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 `APPEND_*` version must be used when the macro invocation appears after a normal parameter declaration or after the invocation of another macro of this same group.
`BOOST_USE_FACET(Type, loc)`	When the standard library does not have a comforming `std::use_facet` there are various workarounds available, but they differ from library to library. This macro provides a consistent way to access a locale's facets. For example, replace: `std::use_facet<Type>(loc);` with: `BOOST_USE_FACET(Type, loc);` Note do not add a `std::` prefix to the front of `BOOST_USE_FACET`.
`BOOST_HAS_FACET(Type, loc)`	When the standard library does not have a comforming `std::has_facet` there are various workarounds available, but they differ from library to library. This macro provides a consistent way to check a locale's facets. For example, replace: `std::has_facet<Type>(loc);` with: `BOOST_HAS_FACET(Type, loc);` Note do not add a `std::` prefix to the front of `BOOST_HAS_FACET`.
`BOOST_NESTED_TEMPLATE`	Member templates are supported by some compilers even though they can't use the `A::template member<U>` syntax, as a workaround replace: `typedef typename A::template rebind<U> binder;` with: `typedef typename A::BOOST_NESTED_TEMPLATE rebind<U> binder;`
`BOOST_STRINGIZE(X)`	Converts the parameter `X` to a string after macro replacement on `X` has been performed.
`BOOST_JOIN(X,Y)`	This piece of macro magic joins the two arguments together, even when one of the arguments is itself a macro (see 16.3.1 in C++ standard). This is normally used to create a mangled name in combination with a predefined macro such a __LINE__.
`BOOST_FORCEINLINE`	This macro can be used in place of the `inline` keyword to instruct the compiler that a function should always be inlined. Overuse of this macro can lead to significant bloat, while good use can increase performance in certain cases, such as computation-intensive code built through generative programming techniques. 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 `inline` before including the Boost.Config header in order to be able to debug errors more easily.

Boost Informational Macros

The following macros describe boost features; these are, generally speaking the only boost macros that should be tested in user code.

Macro	Header	Description
`BOOST_VERSION`	`<boost/version.hpp>`	Describes the boost version number in XYYYZZ format such that: `(BOOST_VERSION % 100)` is the sub-minor version, `((BOOST_VERSION / 100) % 1000)` is the minor version, and `(BOOST_VERSION / 100000)` is the major version.
`BOOST_NO_INT64_T`	`<boost/cstdint.hpp>` `<boost/stdint.h>`	Defined if there are no 64-bit integral types: `int64_t`, `uint64_t` etc.
`BOOST_NO_INTEGRAL_INT64_T`	`<boost/cstdint.hpp>` `<boost/stdint.h>`	Defined if `int64_t` as defined by `<boost/cstdint.hpp>` is not usable in integral constant expressions.
`BOOST_MSVC`	`<boost/config.hpp>`	Defined if the compiler is really Microsoft Visual C++, as opposed to one of the many other compilers that also define `_MSC_VER`. Has the same value as _MSC_VER.
`BOOST_MSVC_FULL_VER`	`<boost/config.hpp>`	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.
`BOOST_INTEL`	`<boost/config.hpp>`	Defined if the compiler is an Intel compiler, takes the same value as the compiler version macro.
`BOOST_CLANG`	`<boost/config.hpp>`	Defined to 1 if the compiler is the Clang compiler.
`BOOST_WINDOWS`	`<boost/config.hpp>`	Defined if the Windows platform API is available.
`BOOST_DINKUMWARE_STDLIB`	`<boost/config.hpp>`	Defined if the dinkumware standard library is in use, takes the same value as the Dinkumware library version macro `_CPPLIB_VER` if defined, otherwise 1.
`BOOST_NO_WREGEX`	`<boost/regex.hpp>`	Defined if the regex library does not support wide character regular expressions.
`BOOST_COMPILER`	`<boost/config.hpp>`	Defined as a string describing the name and version number of the compiler in use. Mainly for debugging the configuration.
`BOOST_STDLIB`	`<boost/config.hpp>`	Defined as a string describing the name and version number of the standard library in use. Mainly for debugging the configuration.
`BOOST_PLATFORM`	`<boost/config.hpp>`	Defined as a string describing the name of the platform. Mainly for debugging the configuration.

Macros for libraries with separate source code

Macros controlling shared library symbol visibility
ABI Fixing
Automatic library selection

The following macros and helper headers are of use to authors whose libraries include separate source code, and are intended to address several issues:

Controlling shared library symbol visibility
Fixing the ABI of the compiled library
Selecting which compiled library to link against based upon the compilers settings

See Guidelines for Authors of Boost Libraries Containing Separate Source

Macros controlling shared library symbol visibility

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
`BOOST_SYMBOL_EXPORT`	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.
`BOOST_SYMBOL_IMPORT`	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.
`BOOST_SYMBOL_VISIBLE`	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.
`BOOST_HAS_DECLSPEC`	The compiler has C++ extensions `__declspec(dllexport)` and `__declspec(dllimport)` to control export/import of symbols from shared libraries. Deprecated. This macro is no longer necessary since BOOST_SYMBOL_EXPORT and BOOST_SYMBOL_IMPORT are now supplied. It is provided to support legacy code.

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()
{
  ...
}
...

ABI Fixing

When linking against a pre-compiled library it vital that the ABI used by the compiler when building the library matches exactly the ABI used by the code using the library. In this case ABI means things like the struct packing arrangement used, the name mangling scheme used, or the size of some types (enum types for example). This is separate from things like threading support, or runtime library variations, which have to be dealt with by build variants. To put this in perspective there is one compiler (Borland's) that has so many compiler options that make subtle changes to the ABI, that at least in theory there 3200 combinations, and that's without considering runtime library variations. Fortunately these variations can be managed by #pragma's that tell the compiler what ABI to use for the types declared in your library. In order to avoid sprinkling #pragma's all over the boost headers, there are some prefix and suffix headers that do the job. Typical usage is:

my_library.hpp

#ifndef MY_INCLUDE_GUARD
#define MY_INCLUDE_GUARD

// all includes go here:
#include <boost/config.hpp>
#include <whatever>

#include <boost/config/abi_prefix.hpp> // must be the last #include

namespace boost {

// your code goes here

}

#include <boost/config/abi_suffix.hpp> // pops abi_prefix.hpp pragmas

#endif // include guard

my_library.cpp

...
// nothing special need be done in the implementation file
...

The user can disable this mechanism by defining BOOST_DISABLE_ABI_HEADERS, or they can define BOOST_ABI_PREFIX and/or BOOST_ABI_SUFFIX to point to their own prefix/suffix headers if they so wish.

Automatic library selection

It is essential that users link to a build of a library which was built against the same runtime library that their application will be built against -if this does not happen then the library will not be binary compatible with their own code- and there is a high likelihood that their application will experience runtime crashes. These kinds of problems can be extremely time consuming and difficult to debug, and often lead to frustrated users and authors alike (simply selecting the right library to link against is not as easy as it seems when their are 6-8 of them to chose from, and some users seem to be blissfully unaware that there even are different runtimes available to them).

To solve this issue, some compilers allow source code to contain #pragma's that instruct the linker which library to link against, all the user need do is include the headers they need, place the compiled libraries in their library search path, and the compiler and linker do the rest. Boost.config supports this via the header <boost/config/auto_link.hpp>, before including this header one or more of the following macros need to be defined:

BOOST_LIB_NAME: Required: An identifier containing the basename of the library, for example 'boost_regex'.
BOOST_DYN_LINK: Optional: when set link to dll rather than static library.
BOOST_LIB_DIAGNOSTIC: Optional: when set the header will print out the name of the library selected (useful for debugging).

If the compiler supports this mechanism, then it will be told to link against the appropriately named library, the actual algorithm used to mangle the name of the library is documented inside <boost/config/auto_link.hpp> and has to match that used to create the libraries via bjam 's install rules.

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