|
Boost : |
From: Jens Maurer (Jens.Maurer_at_[hidden])
Date: 2002-01-02 15:30:16
Vesa Karvonen wrote:
> Currently the preprocessor library contains one special-case workaround for a
> specific buggy preprocessor. Also the list data structure currently under
> construction also contains a couple of workarounds for buggy preprocessors.
> Many more preprocessor bugs have been discovered in various compilers. I
> totally hate the idea of doing extra work to hide preprocessor bugs. It only
> slows down the process of getting more compliant compilers.
Have you reported all the bugs that you found to the respective vendors?
> Alternatively, I'm considering the possibility of using
> BOOST_NO[_COMPILER]_CONFIG to disable workarounds for buggy compilers (at
> library author's discretion). Running the regression tests with a config for a
> fully standards compliant compiler, the regression test suite could be used
> for conformance testing and the results could be posted on the Boost site.
I'd be happy to do so (a separate HTML page) for the Unix platform
test results that I maintain.
Note, however, that some libraries use something like __BORLANDC__
directly, so BOOST_NO_CONFIG wouldn't exactly help those.
I'm all in favor of having a BOOST_CONFIG_PREPROCESSOR_BUGGY config
item with an appropriate test, however. This would solve the
"conformance test" issue. (Or several, with _BUGGY replace by
appropriate verbiage for each specific bug.)
> On the other hand, concise conformance tests could also be very useful for
> compiler vendors for regression testing, so it might be useful to have both
> freely available.
Boost.Config, in particular the detailed tests in libs/config/test, should
solve that issue, I think.
Jens Maurer
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk