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 would (most likely) compile and run properly if the test did not use list_of() with boost::array. I would be very happy to see an intel programmer submit a patch. It is quite strange that it only happens on intel's windows compilers. 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 does not work for this compiler. The test depends on Boost.Tuple which probably does not work for this compiler. 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 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. There something non-standard about the tru64 standard library which is preventing these tests from compiling. 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. 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. 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. 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. 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.

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. 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. 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 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. For other compilers it is simply a bug in the standard library. This failure is of no importance to this compiler. 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. 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. SunOS does not provide static versions of -lrt or -lpthread, and gcc -static refuses to link with any shared objects, so these tests don't compile. 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. 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.