Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
From: Paul A. Bristow (pbristow_at_[hidden])
Date: 2013-07-31 09:32:11
> -----Original Message-----
> From: Boost [mailto:boost-bounces_at_[hidden]] On Behalf Of Stephen Kelly
> Sent: Wednesday, July 31, 2013 1:58 PM
> To: boost_at_[hidden]
> Subject: Re: [boost] Removing old config macro and increasing compiler requirements.
> On 07/29/2013 01:17 PM, Stephen Kelly wrote:
> > Grepping indicates that that means increasing the compiler
> > requirements to something like __DMC__ > 0x840, GCC > 3.2,
> > BOOST_INTEL_CXX_VERSION > 500,
> > VC++ > 7.0.
> Please see the attached patches. One of them bumps the compiler requirement, but far too
> conservatively. I'd suggest bumping it far more. Having such a low compiler requirement means that
> some cases workarounds are needed for libraries which do not otherwise need the workarounds. Such
> workarounds are implemented using other boost libraries, and therefore some lateral dependencies
> between libraries exist purely because of the low minimum compiler requirement.
> If you want to modularize properly, you'll have to cut such lateral dependencies, and that means
> updating the compiler requirement. Users of ancient compilers can use ancient boost, right?
Is a reason for reluctance to do this (apart from the work involved) that we have no very effective
way of warning users of these compilers ahead of time? Posting on the web site isn't much good
because people don't study it - and it is clutter for most who are using other compilers.
Can we produce a "skull-and-bones" compile-time message on the lines of "This is the last time that
this will work!"?
To catch people's attention, using an soon-to-be obsolete compiler or feature would have to produce
an compile-fail error at first, but one that could be countermanded by users then making some macro
definition meaning "I have read and understood the previous warning" so that it would compile.
This would loudly warn that this is the last version of Boost that will work, so they can either
stick to that version, or upgrade compiler etc.
--- Paul A. Bristow, Prizet Farmhouse, Kendal LA8 8AB UK +44 1539 561830 07714330204 pbristow_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk