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.