[boost] Re: int_const_guidelines out of date?

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