From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-12-05 17:05:50
> 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:
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?
#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.