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: Edward Diener (eldiener_at_[hidden])
Date: 2011-08-13 18:31:01

On 8/13/2011 12:18 PM, Joel falcou 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 ?

I would be in favor of just creating an alternate set of files for only 
those compilers which do not need the exotic workarounds and are largely 
conformant to the C++03 standard. I would not throw out what already 
exists. You could then offer an MPL library that is frozen as it is now 
for the very few still needing to use the older compilers and a new MPL 
with none of the elaborate workarounds that were needed in the past and 
in which the code is much more understandable. You could do this as 
Filesystem has done their transition from 2 to 3. The new set of files ( 
same names within a different tree ) would be the default and some macro 
#define would point one to the old tree for the few people who are still 
using the older compilers. But do not spend even one second of your time 
trying to fix or change anything within the older tree; its frozen and 
will remain that way. Once you have the new tree in place, without the 
endless #ifdefs for older compiler workarounds, it should be much easier 
to update MPL with fixes and possible improvements.

>
> <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>

The problem is simply that very few compilers really support the vast 
majority of C++11 features at this moment. So while it should certainly 
be a goal to support C++11 any library which is based on it will find 
very few compilers for awhile.