"AlisdairM" wrote:
If the intent is to produce clearer maintainable libraries by stripping out the large number of workarounds for very broken compilers, then I could probably swallow my self interest in favour of a cleaner boost.
I'd suggested such move (under name Boost 2.0) some time ago: http://lists.boost.org/Archives/boost/2004/03/62626.php In discussion I got convinced this is huge undertaking, not feasible even in long term.
My most pressing concern is that a new Borland compiler just landed in my hands with a new version number, __BORLANDC__ == 0x580. This instantly fails more libraries than the last version, because some libraries coded a workaround specifically for 0x564. I would really like to see those workarounds updated (and will be submitting a list of patches this week) but why would these patches be accepted if there is no more support?
The #if BOOST_WORKAROUND(__BORLANDC__, BOOST_TESTED_AT(0x???)) is used in libraries I had chance to look at. I hope at least this works.
BTW, early experiments with the new Borland compiler show it has some very significant fixes in the code generator, which never really showed up in the Boost tests. The front end, which Boost does catch, seems to have a similar level of 'boost compatibility' to the previous compiler though. I think it is going to pass more test, but it will be better support for existing libraries, rather than supporting more libraries.
Ouch. Not a good news :-( The workarounds using BOOST_TESTED_AT can be switched off (described in docs). It may be interesting to compare number of errors with existing workarounds and without them, whether something in front-end actually got better. /Pavel