The compiler does not support features that are essential for the library. The test fail with ICE, but the exact reason for ICE is not known. A minimal example of casting any to reference type seem to work. Anyone interested in using this functionality with msvc is suggested to do additional testing. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. This test could probably be made to work if somebody with knowledge about the compilers would submit a patch. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The test could probably be made to work if somebody submitted a patch. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test depends on Boost.Pointer Container which probably does not work for this compiler. The test does not work for this compiler. The test depends on Boost.Tuple which probably does not work for this compiler. This failure is caused by Boost.Function. This failure is caused by a bug in the compiler triggered by the use of the debug flag '-gall'. It has been reported to the compiler vendor. The serialization library does not support this compiler. XML serialization is not supported on this compiler. The serialization library does not support this compiler. XML serialization is not supported on this compiler. These are strange runtime failures for which there is no obvious explanation. Later versions of the Intel compiler (eg:8.0) seem to have resolved the issue. For some reason Code Warrior has difficulty compiling some of the input code. This may be related to limitations of locale handling, but it's unclear at this time (2005-May-21). Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some older compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. Some compilers are confused by the template code here. These are new features to date-time in 1.33 and there is no plan to backport to these non-compliant compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. These compilers are unfortunately able to correctly compile the new format-based input-output code for date time. Suitable, but less flexible, alternatives are available on these compilers. Although these tests compile, the execution aborts for an unknown reason. Note that sometimes the excution is ok on cw-9_4. This may be fixable if someone can track down the source of the problem. These tests are failing with the beta2 version of VC_8. At least one of them is directly a result of the new VC_8 standard library restricting the year value in a tm struct to be positive (that is greater than year 1900). This is a change from VC7_1 and Microsoft is considering removing this restriction. The failure is caused by a standard library bug. It doesn't support used defined facets which are not default constructible. This has been reported to the compiler vendor. The failure is caused by a standard library bug. The end-of-stream istream iterator can only be constructed when the istream iterator has been instantiated with char as the character type. This has been reported to the compiler vendor. Due to to standard library bugs this configuration is not supported by the most recent version of the library. The library is mostly working, the test failure observed might be due to a bug in the C library of this platform. This compiler does not support the Boost.Range library, on which Boost.Foreach depends. This compiler does not support detection of const rvalues. This compiler does not support detection of rvalues. These compilers cannot handle BOOST_FOREACH in a template, where the collection type depends on a template parameter. This failure is because the Boost.Range extension mechanism is broken on these compilers. It requires ADL which these compilers do not support. The failure is caused by a standard library bug: the iostream components fail to handle ios::internal flag. hash_value is not overloaded for arrays for older versions of Visual C++. There is a work around so that boost::hash<T[N]>, boost::hash_combine and boost::hash_range work. On this compiler the hash function is returning the same value for std::numeric_limits<long double>::max(), std::numeric_limits<long double>::max() / 2 and std::numeric_limits<long double>::max() * 3 / 4. This suggests the hash function isn't taking into account the full range of long double - it might be converting it to a double. This won't cause anything to break, but means that the hash function isn't as good as it should be for long doubles. These examples only work on compilers with support for ADL. It is possible to work around this, but I wanted to keep the example code as clean as possible. It appears that Borland doesn't find friend functions defined in a class by ADL. This is easily fixed but this example is meant to show the typical way of customising boost::hash, not the portable way. compiler can't compile "windows.h" in strict mode The failure reflects a problem with the build system: the zlib object files are generated in the wrong directory. The compiler is not supported by the library due to an utterly broken templates support. This failure is caused by a deficient SFINAE implementation; the bug was fixed in the next major compiler version (CodeWarrior 9.x). This failure is caused by a deficient SFINAE implementation. This failure is caused by a lack of compiler support for template template parameters. This is an advanced functionality that hasn't been ported to the deficient compilers (yet). Patches are welcome! This is an advanced functionality that hasn't been ported to the deficient compilers (yet). Patches are welcome!

This library has never worked [on Borland 5.5.1 and 5.6.4], and the only tests that 'pass' are compile-fail tests failing for the wrong reasons!

Known error in MSVC. see http://boost-consulting.com/boost/libs/multi_index/doc/compiler_specifics.html#msvc_60 for more information. The VC++ 6.0 backend runs out of internal resources while trying to process the Comeau output for this library; Comeau Computing has been asked about a solution. On the other hand, Comeau 4.3.3 with VC++ 7.0 backend works fine. This error shows when using the dynamic version of the STLport library. The problem is reportedly fixed in STLport 5.0 (in beta stage as of this writing.) Boost.Serialization is not supported on this platform. Borland compilers don't handle templates with array type arguments properly. msvc 6 compiler failure. The facility being tested conflicts the the compiler in a fundamental way and cannnot be worked around. msvc 6 compiler failure. The facility being tested conflicts the the compiler in a fundamental way and cannnot be worked around. This failure appears when STLPort is built and used as a DLL with msvc 6. STLPort suggests that the next version of STLPort(5.0) will include a workaround for this problem. The library is believed to work in this configuration if compiled against Spirit 1.6. The latter is not provided by the particular testing environment these tests have been run in. All tests that serialize derived pointers currently fail with Metrowerks compilers. This is caused by a compiler bug in this particular version, but not present in version thereafter. The compiler has some difficulties resolving operators to methods in the archive classes. This can be worked around by calling the operator directly, and such a work around is already present in library code. This test demonstrates that this can happen in user code. The CW compilers have problems with the static construction idiom used to implement the type registration in the Boost.Serialization library. In many cases CW specific work arounds are implemented in the library but this one is not immediately solvable. There is a user work around possible, please contact the library developers on the Boost list for information on the work around if needed. The variant library is not supported for this compiler version. Therefore serialization of variants doesn't work.

Historically, Spirit supported a lot of compilers, including (to some extent) poorly conforming compilers such as VC6. Spirit v1.6.x will be the last release that will support older poorly conforming compilers. Starting from Spirit v1.8.0, ill conforming compilers will not be supported. If you are still using one of these older compilers, you can still use Spirit v1.6.x.

The reason why Spirit v1.6.x worked on old non-conforming compilers is that the authors laboriously took the trouble of searching for workarounds to make these compilers happy. The process takes a lot of time and energy, especially when one encounters the dreaded ICE or "Internal Compiler Error". Sometimes searching for a single workaround takes days or even weeks. Sometimes, there are no known workarounds. This stifles progress a lot. And, as the library gets more progressive and takes on more advanced C++ techniques, the difficulty is escalated to even new heights.

Spirit v1.6.x will still be supported. Maintenance and bug fixes will still be applied. There will still be active development for the back- porting of new features introduced in Spirit v1.8.0 (and Spirit 1.9.0) to lesser able compilers; hopefully, fueled by contributions from the community. For instance, there is already a working AST tree back-port for VC6 and VC7 by Peder Holt.

This failure is caused by a compiler bug that manifests itself in the particular environment/hardware configuration the test has been run in. You may or may not experience this issue in your local setup. This compiler is not supported. Native mode is not supported for this compiler. Emulation mode is not supported for this compiler. This failure is caused by a compiler bug. Templated operators that combine different iterators built with iterator_facade or iterator_adaptor may be present in an overload set even when those iterators are not interoperable. The usual result is that error messages generated by illegal use of these operators will be of lower quality. This failure is caused by a compiler bug. is_convertible<T,U>::value may be true for unrelated iterators T and U (including many of the Boost specialized adaptors) which use enable_if_convertible to restrict the applicability of converting constructors, even when T is not convertible to U because instantiating the conversion will cause a compilation failure. This failure is caused by a compiler bug. The compiler tends to drop const-ness and as a result some indirect_iterators will have pointer and reference members of T* and T& that should have been T const* and T const&. There appears to be a bug in gcc's std::exp (long double) on this platform. std::numeric_limits>long double<::infinity() is apparently broken in this compiler: it's filed as bug 6347520 with Sun. Incomplete std::complex support make these tests pointless (the complex trig functions are absent). This test ensures the inclusion property of interval arithmetic is available for built-in floating-point types float and double. If the test fails, interval<float> and interval<double> should not be used on this compiler/platform since there will be no numerical guarantee. The failure is caused by standard library deficiencies -- it lacks the basic_string class template and the <locale> header. The failures are caused by problems with std::locale implementation The failures are caused by compiler bug: it's not possible to explicitly pass template arguments to member template function. The failure is serious and makes one of the primary interfaces unusable. The error is due to problems in the standard library implementation. It should be fixed in newer versions of the compiler. The error is due to problems in the standard library implementation. It should be fixed in newer versions of the compiler. The library fails to compile because of an error in the C++ standard library implementation on this platform. It incorrectly assumes that fpos_t is of an integral type, which is not always the case. This is fixed in a later release. The problems with GCC 2.x only occur when C++ exceptions are thrown and the framework catches them, which happens quite often in the tests. So technically GCC 2.x is usable if you're careful. The library is known to work in this configuration. The failures are due to configuration issues of the particular testing environment these tests have been run in. The regression runners and library developers are aware of the problem and plan to fix it for the next release. The test is known to work in this configuration. The failures are due to configuration issues of the particular testing environment these tests have been run in. Test fails with ranlux*_O1 RNGs when saving and recalling the state due to a bug in the double to string conversion. The problem has been reported to QNX as PR29252. For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem. For other compilers it is simply a bug in the standard library. This test probably fails because it uses built-in arrays. So do expect these functions to work in normal code. The string functionality is expected to work if the user employs std::string and stays away from built-in arrays. For most compilers this is due to problems with built-in arrays (notably char arrays) and operator==() and operator!=() for iterator_range. Thus, not using built-in arrays fixes the problem. At the time of release I couldn't figure out why this was failing. Anyway, the failure is not very important; also, the well-definedness of "singularity" of an iterator range is likely to change. This test requires features that are unsupported by Como: use and building of dll's mainly. This test requires features that are unsupported by Como: use and building of dll's mainly. This test fails because a dependency (Boost.Program Options) doesn't build with this compiler. Test fails due to unresilved externals from STLport: appears to be an STLport bug. A runtime failure of this test indicates that this platform dynamically links code in a manner such that under certain circumstances more than one instance of a header-defined static class member can exist at runtime. See here for more information. A runtime failure of this test indicates that this platform statically links code in a manner such that under certain circumstances more than one instance of a header-defined static class member can exist at runtime. See here for more information. This functionality has not been implemented yet. The library developers plan to implement it for the next release. This failure is caused by a conflict between the compiler and the testing environment: the tests are run on a platform with too recent version of glibc, which is not currently supported by the compiler vendor (Intel). If you are having the same problem and really want to make things work, renaming strol symbol in the compiler's static runtime library (libcprts.a) to something else is known to resolve the issue. This failure is caused by the lack of compiler support for class template partial specialization. A limited subset of the tested functionality is available on the compiler through a user-side workaround (see http://www.boost.org/libs/type_traits/index.html#transformations for details). This functionality is available only on compilers that implement C++ Core Language Defect Report 337. The Type Traits library is broken when used with Sunpro-5.3 and the argument to the template is an array or function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. Older versions of MWCW incorrectly align pointers to member functions (they use 12-byte boundaries, rather than a power-of-2 boundary), leading to alignment_of / aligned_storage to fail with these types on this compiler. VC6 has a buggy using declaration syntax which basically makes it impossible to implement the namespace forwarding that this library relies upon. See KB article 263630 here: http://support.microsoft.com/default.aspx?scid=kb;en-us;263630 Metrowerks Codeworrier has partial TR1 support built in which conflicts with this implementation. Porting to this compiler is almost certainly possible, but will require some work by someone who has this compiler. These tests test features that are not supported in the current Boost implementations of TR1 components, they will currently fail on all compilers, unless that compiler has native TR1 support. These tests fail on this platform due to a lack of wide character support. Support for Borland C++ in the various TR1 libraries is pretty poor (due to numerous compiler bugs sadly). The TR1 concept checks are *very* strict, and are expected to fail with this compiler. In addition most of the type_traits tests fail whenever debugging support is turned on with an internal compiler error. More conservative uses are more likely to succeed with this compiler however. These tests fail on this platform due to a recuring GCC bug. These tests fail due to a known compiler bug that is fixed in more recent releases. Users are very unlikely to encounter this as a real problem in practice. These tests fail due to a known compiler bug that is fixed in more recent releases. Users are very unlikely to encounter this as a real problem in practice. These tests fail due to a known compiler bug that is fixed in more recent releases. This functionality may not be usable with this compiler. These tests fail due to a known stdlib bug that has been reported to the vendor. This failure is caused by the lack of compiler support for class template partial specialization. A limited subset of the tested functionality is available on the compiler through a user-side workaround (see http://www.boost.org/libs/type_traits/index.html#transformations for details). This functionality is available only on compilers that implement C++ Core Language Defect Report 337. The Type Traits library is broken when used with Sunpro-5.3 and the argument to the template is an array or function type. Most other argument types do work as expected: in other words the functionality is limited with this compiler, but not so much as to render the library unuseable. Older versions of MWCW incorrectly align pointers to member functions (they use 12-byte boundaries, rather than a power-of-2 boundary), leading to alignment_of / aligned_storage to fail with these types on this compiler. This failure is caused by a compiler bug (default-constructed scalar types are not zero-initialized) that has been fixed in the latest versions of the compiler (VC 7.1 and greater). This toolset isn't supported because of the used Spirit V1.8.x, which in turn is not usable with this toolset. These compilers do not support class template partial specialization. Boost.Fusion doesn't work on this compiler. This compiler doesn't support SFINAE / enable_if Digital Mars cannot seem to handle dependent default template parameters, such as "template < class T, bool B = is_foo < T > ::value >" This test fails only intermittently. The failure is caused by a problem in Boost code. The Boost developers is aware of the problem and plan to fix it. The failure is caused by a compiler bug. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a standard library bug. The failure is caused by a standard library bug, which has been reported to the standard library supplier (or is already known to them). The failure is probably caused by the test code, harness, or configuration. Thus it may not affect users of the library. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is serious and likely to prevent all use of this Boost library with this compiler. The failure is caused by a compiler bug, which has been reported to the compiler supplier (or is already known to them). The failure is caused by a platform API bug. The failure is caused by a platform API bug, which has been reported to the platform API supplier (or is already known to them). The failure is not serious and will not affect most users. The library degrades gracefully. This compiler's bugs are not supported by the library. Locales missing or adequately supported by this compiler. Missing or inadequate wchar/wstring/wstream support for this compiler. No std iterator traits for this compiler. Library has limited input/output support due to compiler inadequacies. No high precision clock for this platform. A bug in standard library prevents passing std::set from DLL to application. A fixed <tree> header is available from http://www.dinkumware.com/vc_fixes.html. Although the documentation from the Comeau website would make it appear that windows DLL's are supported using the --windows option, after some experimentation we have been unsuccessful in making dll configurations work correctly. The failure is caused by a runtime limitation. Locale support is only available with the static linked variant of the runtime. Generally the dynamic linked variant is required when building dynamic modules, DLL, so, etc. This failure is caused by a compiler bug with no known workaround. Patches are welcome! This failure is caused by bugs in the standard library implementation and/or bugs in the compiler. Unresearched failure, please contact library developers for more information about possible causes. The test fails due to unresearched issues. The library developers are aware of this failure, but need help with investigating/addressing it for future releases. The support for this deficient compiler will be dropped starting from Boost 1.33.0 release. Please use one of the previous Boost releases if you need the library to work on this compiler. This failure is caused by compiler bugs or limitations. Some advanced or esoteric library features may be unavailable or only partially available. This does not impact most common uses of the library. This failure is caused by a compiler bug. Certain code constructs that should fail compilation are accepted by the compiler. This can mask some programming errors, but does not impact the usability of the library. The failures are caused by the wrong handling of the std::internal flag in the iostreams implementation of the standard library used on that compiler/platform combo. Apart from that, the format library works as expected. The failures are caused by the fact that the iword and pword arrays seem to share the same memory area in the iostreams implementation of the standard library used on that compiler/platform combo. As long as you stay clear of iword and pword, the library should work ok. This failure occurs only when using shared libraries for this compiler and platform, although the same programs should work properly when using static libraries. This problem has not been researched. Wide character support is disabled in the GNU Standard C++ library as supplied on the QNX Neutrino version 6.3.0 distribution.