The Lonely Song of the MPL Maintainer -- or Boost support for antediluvian compiler and the future supprot of C++11
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 ?
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 ?
I fully support the motion to get started with Boost V2, which should be to C++11 what Boost was originally to C++98. Today we know that the infrastructure libraries are needed most, so why not leave the existing MPL alone and start over? We already have the C++11 version of Fusion and given the fact, that MPL is mostly a clean subset of Fusion anyways we should have a head start already. Regards Hartmut --------------- http://boost-spirit.com
On Aug 13, 2011, at 1:21 PM, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
so why not leave the existing MPL alone and start over?
Is there any reason a variadic MPL would have a different interface? I.e. could we have a clean MPL'11 with the same interface, and leave the old workarounds to rot?
Gordon Woodhull <gordon@woodhull.com> writes:
On Aug 13, 2011, at 1:21 PM, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
so why not leave the existing MPL alone and start over?
Is there any reason a variadic MPL would have a different interface?
Yep. There are plenty of cases in MPL where variadic interfaces would be useful, sequence construction being a primary one. It is a royal pain to convert a C++11 variadic type list into an MPL vector, for example. -Dave
On Mon, Aug 15, 2011 at 11:56 AM, David A. Greene <greened@obbligato.org>wrote:
Gordon Woodhull <gordon@woodhull.com> writes:
On Aug 13, 2011, at 1:21 PM, "Hartmut Kaiser" <hartmut.kaiser@gmail.com> wrote:
so why not leave the existing MPL alone and start over?
Is there any reason a variadic MPL would have a different interface?
Yep. There are plenty of cases in MPL where variadic interfaces would be useful, sequence construction being a primary one. It is a royal pain to convert a C++11 variadic type list into an MPL vector, for example.
Sorry for the ignorance, but it isn't as simple as boost::mpl::vector< T...
? Or does that indeed qualify as a "royal pain" ?
- Jeff
On Mon, Aug 15, 2011 at 12:31 PM, Joel falcou <joel.falcou@gmail.com> wrote:
On 15/08/11 21:26, Jeffrey Lee Hellrung, Jr. wrote:
Sorry for the ignorance, but it isn't as simple as boost::mpl::vector< T...
You can not pass a template argument pack to a old fashioned enuemrated list of template parameters.
Well...that sucks. I hope it's not too off-topic to ask for motivation why this isn't possible... - Jeff
Perhaps you might want to consider making a newer version of the mpl library and call it mpl2. This new version would work only be guarenteed to work on the most modern compilers. The advantages of doing this would be a) You wouldn't have to compromise by trying to support older compilers b) You could work at peace since the current mpl would be around for the forseeable future c) by using mpl2 namespace and directory - there would be no conflict with the current version. Users could select one or the other. d) Review/criticism etc would be simpler since the current version would still be around. Robert Ramey
On 16 August 2011 00:07, Robert Ramey <ramey@rrsd.com> wrote:
This new version would work only be guarenteed to work on the most modern compilers.
This assumption seems to permeate this entire thread, and I'm not understanding it. The compatibility problem is about to get worse, not better, IMHO. We are moving from a mature language spec to a brand new one. I fully expect changes between compiler revs (let alone different compiler vendors) to be much more prolific in the next couple of years than they have been in the previous couple of years, as features are implemented, the language itself is fixed, tools are debugged, etc. Draw a line in the sand and get rid of the old cruft if you desire, but the fundamental problem is not going to go away... -- Nevin ":-)" Liber <mailto:nevin@eviloverlord.com> (847) 691-1404
On 16/08/11 08:48, Nevin Liber wrote:
On 16 August 2011 00:07, Robert Ramey<ramey@rrsd.com> wrote:
This new version would work only be guarenteed to work on the most modern compilers.
This assumption seems to permeate this entire thread, and I'm not understanding it. The compatibility problem is about to get worse, not better, IMHO.
We are moving from a mature language spec to a brand new one. I fully expect changes between compiler revs (let alone different compiler vendors) to be much more prolific in the next couple of years than they have been in the previous couple of years, as features are implemented, the language itself is fixed, tools are debugged, etc.
Draw a line in the sand and get rid of the old cruft if you desire, but the fundamental problem is not going to go away...
Beware, there is two issues raise din my original post. Let's forget about c++11 for now, this is an orthogonal problem. The main question is: should we sacrifice lisibility and maintainer time to support compiler from before 1492 (hyperbolically speaking of course), compilers which are usually so specific the users probably never upgrade boost anyway. In short, is it time to prune support for very very very old compilers.
I discovered a workaround to this problem. It is a bit annoying in use, but does work: template<template <typename...> class T, typename... Args> struct TypeJoin { typedef T<Args...> type; }; template<typename T1=int,typename T2=int, typename T3=int> struct my_tuple {}; template<typename… T> struct X { // my_tuple<T…> tt; <- This won't compile. typename Join<my_tuple, T…>::type t; }; On 15 Aug 2011, at 20:31, Joel falcou wrote:
On 15/08/11 21:26, Jeffrey Lee Hellrung, Jr. wrote:
Sorry for the ignorance, but it isn't as simple as boost::mpl::vector< T...
You can not pass a template argument pack to a old fashioned enuemrated list of template parameters.
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Aug 15, 2011, at 2:56 PM, greened@obbligato.org (David A. Greene) wrote:
Is there any reason a variadic MPL would have a different interface?
Yep. There are plenty of cases in MPL where variadic interfaces would be useful, sequence construction being a primary one. It is a royal pain to convert a C++11 variadic type list into an MPL vector, for example.
Well that seems like just a compiler bug. I was wondering how else we could expect C++11 to improve the interface of MPL, beyond sequence <-> variadic conversions. But I can be patient and see it when it's ready. :-) Cheers, Gordon
On 08/13/11 12:52, Gordon Woodhull wrote:
On Aug 13, 2011, at 1:21 PM, "Hartmut Kaiser"
<hartmut.kaiser@gmail.com> wrote:
so why not leave the existing MPL alone and start over?
Is there any reason a variadic MPL would have a different interface? I.e. could we have a clean MPL'11 with the same interface, and leave the old workarounds to rot?
There's a "mostly" variadic mpl here: http://svn.boost.org/svn/boost/sandbox/variadic_templates/boost/mpl/ which works with a later g++ compiler (> 4.5 I think) which does "leave the old > workarounds" by just using another compiler flag, -I<variadic_templates> (where <variadic_templates> is the above directory), in front of other -I flags (including the one to the non-variadic boost) to get the variadic version of the mpl templates. I say "mostly" because the compiler does use the non-variadic mpl files if they're not found in the variadic boost directory. The <variadic_template>/boost/mpl directory does have a few new templates, such as those in: fold_assoc*.hpp which are meant to mimic those in haskell, and: while.hpp which does what the filename suggests. HTH. -regards, Larry
Rather than expect any library owner/maintainer to manage development of a C++11 and maintain the v1 library, it might be best to assign a new person to maintain the v1 library, at least for as long as v2 development takes. On Sat, Aug 13, 2011 at 1:21 PM, Hartmut Kaiser <hartmut.kaiser@gmail.com>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 ?
I fully support the motion to get started with Boost V2, which should be to C++11 what Boost was originally to C++98. Today we know that the infrastructure libraries are needed most, so why not leave the existing MPL alone and start over? We already have the C++11 version of Fusion and given the fact, that MPL is mostly a clean subset of Fusion anyways we should have a head start already.
Regards Hartmut --------------- http://boost-spirit.com
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, Aug 13, 2011 at 12:18 PM, Joel falcou <joel.falcou@gmail.com> 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
I think it's a good idea getting rid of old things from boost and focusing on C++11. That's gonna be a goal in Boost.ublas too. On Sat, Aug 13, 2011 at 17:18, Joel falcou <joel.falcou@gmail.com> 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 ?
______________________________**_________________ Unsubscribe & other changes: http://lists.boost.org/** mailman/listinfo.cgi/boost<http://lists.boost.org/mailman/listinfo.cgi/boost>
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.
On 14/08/11 00:31, Edward Diener wrote:
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.
10 years ago, C++03 was not that supported by many compilers. Boost effort to push the boundaries forced the compiler vendor to adapt adn support more stuff. I think Boost can do the same with C++11: forcing vendors to actually care. I really don't want C++11 go the C99 way because nobody used it. It's a vicious circle : you don't use C++11 cause vendor don't support much so vendor don't add more support cause nobody use it.
On 8/14/2011 2:49 AM, Joel falcou wrote:
On 14/08/11 00:31, Edward Diener wrote:
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.
10 years ago, C++03 was not that supported by many compilers. Boost effort to push the boundaries forced the compiler vendor to adapt adn support more stuff. I think Boost can do the same with C++11: forcing vendors to actually care. I really don't want C++11 go the C99 way because nobody used it. It's a vicious circle : you don't use C++11 cause vendor don't support much so vendor don't add more support cause nobody use it.
I agree with you but any Boost library still has to support C++03 for a good while until compiler vendors catch up with the C++11 standard.
On 14/08/11 14:09, Edward Diener wrote:
I agree with you but any Boost library still has to support C++03 for a good while until compiler vendors catch up with the C++11 standard.
I am : 1/ requesting dropping support for non 03 compliant compiler 2/ starting a C++11 only branch of boost not the mix of both.
Joel falcou-4 wrote:
On 14/08/11 14:09, Edward Diener wrote:
I agree with you but any Boost library still has to support C++03 for a good while until compiler vendors catch up with the C++11 standard.
I am :
1/ requesting dropping support for non 03 compliant compiler 2/ starting a C++11 only branch of boost
not the mix of both.
Hi Joel, I don't know, but I guess that the list of 03 compliant compilers will be quite short. Have you a list? How do you qualify a C++11 only branch? One that supports only C++11 compliant compilers? One that uses only standard C++11 libraries and itself or could libraries on this branch use libraries on the current Boost branch? Could you clarify? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/The-Lonely-Song-of-the-MPL-Maintainer-or-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 14/08/11 16:52, Vicente Botet wrote:
Hi Joel,
I don't know, but I guess that the list of 03 compliant compilers will be quite short. Have you a list?
No, i hope that in 2011, except for stupidly old compiler, everybody support 03. We're not paid to support Borland 4 nor ICC 3 nor g++ 2.95.1
How do you qualify a C++11 only branch? One that supports only C++11 compliant compilers?
Yes and use it as a pushing factor for C++11 support in compilers vendor, the ame way Boost made 03 supported all over the place.
Could you clarify?
See my opening post
I agree with you but any Boost library still has to support C++03 for a good while until compiler vendors catch up with the C++11 standard.
I am :
1/ requesting dropping support for non 03 compliant compiler 2/ starting a C++11 only branch of boost
not the mix of both.
Hi Joel,
I don't know, but I guess that the list of 03 compliant compilers will be quite short. Have you a list?
How do you qualify a C++11 only branch? One that supports only C++11 compliant compilers? One that uses only standard C++11 libraries and itself or could libraries on this branch use libraries on the current Boost branch?
I guess what this comes down to - is what C++11 features do you intend to use? If there are a couple of compilers already supporting what you need, then I suggest you aim for a clean C++11-only MPL if that makes the most sense. We can always call it MPL-2.0 or something and place it in a different tree from "legacy" MPL? John.
Mathias Gaunard-2 wrote:
On 08/14/2011 04:52 PM, Vicente Botet wrote:
I don't know, but I guess that the list of 03 compliant compilers will be quite short. Have you a list?
Recent versions of GCC, Intel compilers, Clang, MSVC, PGI, Comeau, xlC, what else? nvcc maybe, though it's hardly C++03 compliant?
I have a question, is SFINAE_EXPR a C++0x or C++03 feature? If the last, MSVC would be non 03 compliant. Otherwise the Boost.Config configuration should be updated. Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/The-Lonely-Song-of-the-MPL-Maintainer-or-... Sent from the Boost - Dev mailing list archive at Nabble.com.
On 08/14/2011 10:50 PM, Vicente Botet wrote:
Mathias Gaunard-2 wrote:
On 08/14/2011 04:52 PM, Vicente Botet wrote:
I don't know, but I guess that the list of 03 compliant compilers will be quite short. Have you a list?
Recent versions of GCC, Intel compilers, Clang, MSVC, PGI, Comeau, xlC, what else? nvcc maybe, though it's hardly C++03 compliant?
I have a question, is SFINAE_EXPR a C++0x or C++03 feature?
It's possible to have it in C++03, but it's not required before C++0x.
Mathias Gaunard-2 wrote:
On 08/14/2011 10:50 PM, Vicente Botet wrote:
I have a question, is SFINAE_EXPR a C++0x or C++03 feature?
It's possible to have it in C++03, but it's not required before C++0x.
Thanks for the clarification. I was not aware of this detail. In this case you are right the list of c++03 compliant compilers should be larger. John, could this feature have two corresponding macros, one optional feature BOST_HAS_SFINAE_EXPR for c++03 and one defect BOST_NO_SFINAE_EXPR for c++11? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/The-Lonely-Song-of-the-MPL-Maintainer-or-... Sent from the Boost - Dev mailing list archive at Nabble.com.
I have a question, is SFINAE_EXPR a C++0x or C++03 feature?
It's possible to have it in C++03, but it's not required before C++0x.
Thanks for the clarification. I was not aware of this detail. In this case you are right the list of c++03 compliant compilers should be larger.
John, could this feature have two corresponding macros, one optional feature BOST_HAS_SFINAE_EXPR for c++03 and one defect BOST_NO_SFINAE_EXPR for c++11?
At present we already have BOOST_NO_SFINAE_EXPR, adding a second macro just adds unnecessary redundancy IMO. Besides we've sort of already set the president that missing C++11 features have BOOST_NO_ macros and not BOOST_HAS_. John.
John Maddock-3 wrote:
I have a question, is SFINAE_EXPR a C++0x or C++03 feature?
It's possible to have it in C++03, but it's not required before C++0x.
Thanks for the clarification. I was not aware of this detail. In this case you are right the list of c++03 compliant compilers should be larger.
John, could this feature have two corresponding macros, one optional feature BOST_HAS_SFINAE_EXPR for c++03 and one defect BOST_NO_SFINAE_EXPR for c++11?
At present we already have BOOST_NO_SFINAE_EXPR, adding a second macro just adds unnecessary redundancy IMO. Besides we've sort of already set the president that missing C++11 features have BOOST_NO_ macros and not BOOST_HAS_.
The idea was to make evident that SFINAE_EXPR is an optional feature of C++03 and not a defect. However is a mandatory feature of c++11. This macro is on the section associated to defects to the c++03 standard, and should be on the section associated to the c++11 defects, isn't it? Best, Vicente -- View this message in context: http://boost.2283326.n4.nabble.com/The-Lonely-Song-of-the-MPL-Maintainer-or-... Sent from the Boost - Dev mailing list archive at Nabble.com.
I love the title of this post. Robert Ramey
<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>
Joel, you know I'm in favor of this :) but you might want to hold off any serious effort until there are a reasonable number of compilers (say, 2?) supporting variadic templates, decltype and auto, and template aliases -- especially the last. You may find yourself committing designs today that may be dramatically improved with a little extra language support. Andrew
<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>
Joel, you know I'm in favor of this :) but you might want to hold off any serious effort until there are a reasonable number of compilers (say, 2?) supporting variadic templates, decltype and auto, and template aliases -- especially the last. You may find yourself committing designs today that may be dramatically improved with a little extra language support.
<more radical> [With the proviso that I know nothing whatsoever about compiler design/implementation] Has the Boost community ever thought about leveraging its experience to come up with a next-gen successor to C++ (the Boost programming language, maybe)? I started thinking about this during development of Boost.Units; while the power of C++ was evident, the process of implementation was dramatically more complex than the conceptual specification. While there are a number of interesting languages in various stages of development (Chapel/X10/Fortress for HPC, D, etc...), none of them seem to be gaining much traction. It seems like the huge body of experience with the C++ language and with library implementation issues could extremely beneficial in formulating an eventual inheritor that preserves the good, eliminates the bad, and moves programming forward. It seems that one could use the ease of reimplementation of Boost libraries in the new language as a yardstick for success : libraries that are hard to implement would suggest a language deficiency. Don't know if anyone has ever tried open source language development; it might turn out to be a disaster of design by committee or might turn out something really interesting... </more radical> Matthias
on Sat Aug 13 2011, Joel falcou <joel.falcou-AT-gmail.com> 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 ?
Fine with me.
<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>
A separate thread for that question, please.
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 ?
I think it's OK to make any choice you like about compiler support as long as you do it responsibly (e.g. announce it ahead of time, make sure the supported compilers are being tested, etc.) -- Dave Abrahams BoostPro Computing http://www.boostpro.com
Le 13/08/2011 18:18, Joel falcou a écrit :
<radical> 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>
I think this is a really important point. Currently, it is really difficult to use boost with a C++11-aware compiler, because of the similarity of names between boost:: and std:: names. I know namespaces were designed to solve such problems, but except if the user explicitly qualifies every names, problems do occur (1). If boost just forwarded to the standard implementation if available, those problems would disappear. This would also allow a better interoperability between boost-aware code and C++11-aware code (passing a std::shared_ptr to boost.serialization, for instance). (1) Here is an example of a possible problem, this code can (rightly) fails to compile on a C++11 compiler: #include <string> #include <boost/smart_ptr.hpp> #include <boost/make_shared.hpp> using namespace boost; int main() { std::string s = "Hello world!"; shared_ptr<std::string> ptr = make_shared<std::string>(s); } -- Loïc
On Sat, Aug 13, 2011 at 9:18 AM, Joel falcou <joel.falcou@gmail.com> wrote:
<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>
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal. It expect it will be "mostly" compatible with date-time v1, but with some new twists and adjustments -- enough that I want to rewrite the core code. To save time and energy I'm seriously considering requiring C++11 so that I have access to several new features. In my case I have to also contend with Chrono compatibility -- so supporting C++03 requires switching out to boost::chrono etc. As a structure I'm considering simply creating boost/date_time_v2 and libs/date_time_v2 (or date_time_cpp11 if you prefer) and thus the only #ifdef w.r.t C++11 shows up in date_time.hpp With this approach bcp could pull out the correct date-time for C++11 if that's all you wanted. Obviously other libraries could adopt this approach making it easy to get a c++11 version of boost. The big downside to this sort of direction is that it would require 'forking the library'. On the other hand, much of the 'core of boost' (shared_ptr, etc) isn't needed since it's in std:: Jeff
El 21/08/2011 20:54, Jeff Garland escribió:
On Sat, Aug 13, 2011 at 9:18 AM, Joel falcou<joel.falcou@gmail.com> wrote:
<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>
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal. It expect it will be "mostly" compatible with date-time v1, but with some new twists and adjustments -- enough that I want to rewrite the core code. To save time and energy I'm seriously considering requiring C++11 so that I have access to several new features. In my case I have to also contend with Chrono compatibility -- so
IMHO that would be bad news. Until most programmers migrate to a new compiler with C++11 features we'll have to wait for years, enterprise policies are not compatible with changing the already bought licences and environments every yar. Some basic support for C++03 would be nice, we have move emulation and some macro tricks for variadic templates. Just my 2 cents, Best, Ion
2011/8/21 Ion Gaztañaga <igaztanaga@gmail.com>
El 21/08/2011 20:54, Jeff Garland escribió:
On Sat, Aug 13, 2011 at 9:18 AM, Joel falcou<joel.falcou@gmail.com>
wrote:
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>
For what it's worth, I'm currently looking at creating date-time v2 in
<radical> preparation for an updated lwg proposal. It expect it will be "mostly" compatible with date-time v1, but with some new twists and adjustments -- enough that I want to rewrite the core code. To save time and energy I'm seriously considering requiring C++11 so that I have access to several new features. In my case I have to also contend with Chrono compatibility -- so
IMHO that would be bad news. Until most programmers migrate to a new compiler with C++11 features we'll have to wait for years, enterprise policies are not compatible with changing the already bought licences and environments every yar. Some basic support for C++03 would be nice, we have move emulation and some macro tricks for variadic templates. Just my 2 cents,
In my case the C++03 support story would be "use date-time v1" -- the #ifdef in date_time.hpp would handle it as seamlessly as possible with the exception of any interface changes in the library. Keep in mind that my library working group proposal will need to use 0x features to be accepted - constexpr, strong enums, unicode strings, etc. So I have some strong motivation to develop directly in the new language. Since g++ already supports most of what I'm likely to need it makes it easy for me to move forward. I'm also not as certain that there will be a long delay in C++11 adoption. For example, a colleague of mine has been using boost libraries compiled in C++03 mode while using the 0x mode of g++4.6 (on Linux) for his code. If the binary compatibility holds up over time and with other compilers, then a large number of programmers will be able to move forward to 0x since the entire software stack doesn't need to be recompiled. Jeff Jeff
On 8/21/2011 5:36 PM, Ion Gaztañaga wrote:
El 21/08/2011 20:54, Jeff Garland escribió:
On Sat, Aug 13, 2011 at 9:18 AM, Joel falcou<joel.falcou@gmail.com> wrote:
<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>
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal. It expect it will be "mostly" compatible with date-time v1, but with some new twists and adjustments -- enough that I want to rewrite the core code. To save time and energy I'm seriously considering requiring C++11 so that I have access to several new features. In my case I have to also contend with Chrono compatibility -- so
IMHO that would be bad news. Until most programmers migrate to a new compiler with C++11 features we'll have to wait for years, enterprise policies are not compatible with changing the already bought licences and environments every yar. Some basic support for C++03 would be nice, we have move emulation and some macro tricks for variadic templates. Just my 2 cents,
Although it is more work for the Boost library developer I see nothing wrong with creating a version of a library for C++11, while still supporting C++03 in a previous version as long as the C++03 version remains supported as far as fixing bugs and potentially adding new features are concerned. For older Boost libraries which have supported compilers which are completely out of date as far as the C++03 standard is concerned, I also see nothing wrong with creating a separate version which leaves behind endless workarounds produced to support out-of-date compilers and restricting any further work to that version. I think while it is harder to support multiple versions of a library, it is relatively easy via separate directory trees to setup a library for the end-user which supports these different versions. At some point a library developer is justified in dropping support entirely for compilers which nobody should really be using anymore ( ie. VC6, VC7 ). Inevitably as C++11 and even further changes in the C++ standard occur, Boost library developers have a right to tailor their libraries to the latest technology and tell people that they need to use a better compiler, but I agree with you that C++03 support is going to be necessary for a good while yet until major compiler vendors support the C++11 standard as it gets published and promoted.
On Aug 21, 2011, at 2:54 PM, Jeff Garland wrote:
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal.
This is great news Jeff! Howard
On Mon, Aug 22, 2011 at 4:34 PM, Howard Hinnant <howard.hinnant@gmail.com>wrote:
On Aug 21, 2011, at 2:54 PM, Jeff Garland wrote:
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal.
This is great news Jeff!
Glad to hear you think so :-) Is Kona going to be a good meeting for new proposals? Jeff
On Aug 22, 2011, at 8:06 PM, Jeff Garland wrote:
On Mon, Aug 22, 2011 at 4:34 PM, Howard Hinnant <howard.hinnant@gmail.com>wrote:
On Aug 21, 2011, at 2:54 PM, Jeff Garland wrote:
For what it's worth, I'm currently looking at creating date-time v2 in preparation for an updated lwg proposal.
This is great news Jeff!
Glad to hear you think so :-) Is Kona going to be a good meeting for new proposals?
I can't speak for EWG. But absolutely for LWG. Howard
participants (23)
-
Andrew Sutton -
Beman Dawes -
Christopher Jefferson -
Dave Abrahams -
David Bellot -
Edward Diener -
Gordon Woodhull -
greened＠obbligato.org -
Hartmut Kaiser -
Howard Hinnant -
Ion Gaztañaga -
Jeff Garland -
Jeffrey Lee Hellrung, Jr. -
Joel falcou -
John Maddock -
Larry Evans -
Loïc Joly -
Mathias Gaunard -
Matthias Schabel -
Nevin Liber -
Robert Ramey -
Steven Maitlall -
Vicente Botet