The compiler does not support features that are essential for the library. 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 would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The test would (most likely) compile and run properly if the workaround syntax .to_container( c ) was applied to all list_of() expressions. The serialization library does not support this compiler. The serialization library does not support 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. Due to to standard library bugs this configuration is not supported by the most recent version of the library. The failure is caused by a standard library bug: the iostream components fail to handle ios::internal flag. Many compiler-specific workarounds will have to applied before toolset is supported. This failure is a result of an undiagnosed STLPort bug; the test fails even if all Boost components are replaced by standard library components. No wide stream support. No wide stream 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.) 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.

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 failure is caused by a compiler bug in version 14.00.40809 that has been fixed in the latest development "alpha". 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&. 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 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. 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. 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. 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. 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. 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 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 staring from Boost 1.33.0 release. Please use one of the previous Boost releases if you need the library to work on this compiler.