Is portability to pre-standard compiler an issue when considering addition to boost library

If code is proposed to be added to the boost library, and it can not compile on non-compliant (pre-standard) compiler, like VC++ 6.0, would that be a major factor for rejection? I have classes that are fully compliant to the C++ standard, but will not compile on VC++ 6.0, because 6.0 doesn't fully support template logic. Is this a factor in consideration for code addition to the boost library?

Axter wrote:
If code is proposed to be added to the boost library, and it can not compile on non-compliant (pre-standard) compiler, like VC++ 6.0, would that be a major factor for rejection?
No.
I have classes that are fully compliant to the C++ standard, but will not compile on VC++ 6.0, because 6.0 doesn't fully support template logic.
Is this a factor in consideration for code addition to the boost library?
Some people (still!) want to use VC6 because of existing codebases within a company, but there has been a general trend to move away from VC6 support in Boost because it is just too broken and is very easy to make it generate an Internal compiler Error (ICE). For example, the latest versions of Spirit do not support VC6. The only requirement on compiler/platform support for a library to be considered is that it should be tested on more than one compiler vendor. For example VC and GCC. If you publish the code with a description of the library and what it is used for, other Boost developers interested in it will usually test it on the compilers they have and report any issues. Once you feel the library is ready, you can request a formal review. - Reece
participants (2)
-
Axter
-
Reece Dunn