Boost logo

Boost :

From: AlisdairM (alisdair.meredith_at_[hidden])
Date: 2003-11-25 09:33:20


Markus Werle <numerical.simulation_at_[hidden]> wrote in news:bpvlfb$cls$1
@sea.gmane.org:

> But then: why support it[Borland] anyway?
> Considering the retard while designing the racing car
> makes no sense to me.

Well, we use it to support racing cars ;¬ )

> If I remove all BOOST_WORKAROUND which were introduced
> for Borland, my code looks _much_ more readable.

Borland are hard at work on a compiler based on the EDG front end. I
believe future versions will be much less of a pain, although likely
still 12 months or more from release.

In the meantime we existing Borland customers will still have to jump
through those hoops.

Personally, I would be disappointed but could live with new boost
libraries choosing not to support Borland if it is too taxing, although I
am quite prepared to help port libraries I will be using <g>

I would be disappointed to lose the use if libraries that are currently
supported, at least before the new compiler ships. However, I don't
think boost::etl is in this category yet.

I know the Spirit developers are wrestling with the same issue, and it
looks like the next releae will no longer support older compilers such as
Borland and VC-pre-7.1. At least in this case a maintenance branch will
be created of the current release to maintain support for these 'broken'
compilers so we only miss the new goodies and don't lose the old.

Personally I would quite like to see Boost clean up a lot of code
obfuscation for old compilers, and simply say 'Release 1.xx is the last
you get' so we can get some clarity back in the code (some of the
concepts are complicated enough without these workarounds) Of course, I
am talking about dropping support for all compilers other than the one I
actually use myself ;¬ )

Now that modern compilers are much closer to ISO conformance, I wonder
how much more productive Boost might be if we did not require so much
bending over backwards for older compilers? Beyond Borland, what are the
other widespread 'flawed' compilers that respective vendors have not
improved? I'm not familiar enough with the market for non-Windows OSes
to be sure this is the last one, but if so I think this 'cleanup' might
be worth some serious consideration.

AlisdairM


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