Boost logo

Boost :

From: Pavel Vozenilek (pavel_vozenilek_at_[hidden])
Date: 2005-12-05 17:05:50


"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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk