Re: [boost] The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11

Subject: Re: [boost] The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11
From: Beman Dawes (bdawes_at_[hidden])
Date: 2011-08-13 16:03:23

On Sat, Aug 13, 2011 at 12:18 PM, Joel falcou <joel.falcou_at_[hidden]> wrote:

> This is meant to be a serious thread and not some trollfest about w/e
> compilers.
>
> I am currently fixing bugs and applying feature request in MPL and it just
> happens I spend more time deciphering the web of compatibility #ifdefs than
> doing actual code. A rough guestimate tells me that on a 100 lines MPL
> files, 80 of them are #ifdef for compatibility.
>
> It could fine and dandy if those #ifdefs where not, for a majority,
> targeted at compiler i didnt even knew hwere standard conformant (ICC 5,
> really) or still in serious use (Borland whatever). Some other are more
> debatable (like MSVC 6 or such).
>
> Considering such compilers are so broken that upgrading boost is out of
> question for these users and that C++11 and its new set of supporting
> compilers are around the corner, also taking into account my limited amount
> of sanity (IRC people can testify on this), can't we start some support
> clean up in this library ?
>
> <radical>
> Going further, shouldn't we start thinking at boost 2.0 which will
> definitevely let c++03 die its peaceful death and start, on a voluntary
> effort, move boost component toward C++11. I know we have a fully working
> Fusion for 0x only. mpl, proto and other strategic infrastructure libraries
> should benefit from that. Some are a trivial port like Boost.PP and all the
> TR1 boost library that will just either disappear or forward the C++11
> version.
> </radical>
>
> Here is the status of the thingy. Letting Boost 2.0 aside, what should be
> the status of MPL and its sharazadian list of supported compiler ?
>

It isn't just MPL. Many boost libraries are hard to maintain because of
workaround code for compilers that are no longer worth supporting.

So at the very least, it is time to start assuming full C++03 conformance,
and support for the one or two C++0x features like long long that have been
shipping for many compiler releases from virtually all compiler suppliers.
So workarounds for things like BOOST_NO_PARTIAL_SPECIALIZATION can be remove
from libraries during maintenance.

C++0x will be tougher, although it is certainly time to start talking about
exactly what the policy should be.

--Beman