[C++0x][config] Taking advantage of C++0x features as they become available
In another thread, Doug Gregor wrote:
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. Yes, and some other compilers are also starting to add C++0x features.
Has there been any discussion as to how Boost.Config is going to report availability or not of C++0x features? That would seem to be the first step in what promises to be a long, winding, but *very* interesting and productive path. --Beman
On Apr 4, 2008, at 12:35 PM, Beman Dawes wrote:
In another thread, Doug Gregor wrote:
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. Yes, and some other compilers are also starting to add C++0x features.
Has there been any discussion as to how Boost.Config is going to report availability or not of C++0x features? That would seem to be the first step in what promises to be a long, winding, but *very* interesting and productive path.
I started this discussion a while ago: http://lists.boost.org/Archives/boost/2006/11/113534.php Boost 1.35.0 already contains some macros for C++0x features available now, e.g., BOOST_HAS_STATIC_ASSERT (used by boost/static_assert.hpp), BOOST_HAS_VARIADIC_TMPL, BOOST_HAS_RVALUE_REFS, and BOOST_HAS_DECLTYPE. They have their own section of the Boost.Config documentation ("Macros that describe C++0x Features"), and I believe that accurately reflect the capabilities of released compilers. I'm hoping that my BoostCon tutorial on C++0x and Dan & Joel's Fusion0x tutorial will spur some interest in updating Boost libraries with C++0x support. - Doug
Doug Gregor wrote:
On Apr 4, 2008, at 12:35 PM, Beman Dawes wrote:
In another thread, Doug Gregor wrote:
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. Yes, and some other compilers are also starting to add C++0x features.
Has there been any discussion as to how Boost.Config is going to report availability or not of C++0x features? That would seem to be the first step in what promises to be a long, winding, but *very* interesting and productive path.
I started this discussion a while ago:
http://lists.boost.org/Archives/boost/2006/11/113534.php
Boost 1.35.0 already contains some macros for C++0x features available now, e.g., BOOST_HAS_STATIC_ASSERT (used by boost/static_assert.hpp), BOOST_HAS_VARIADIC_TMPL, BOOST_HAS_RVALUE_REFS, and BOOST_HAS_DECLTYPE. They have their own section of the Boost.Config documentation ("Macros that describe C++0x Features"), and I believe that accurately reflect the capabilities of released compilers.
I thought I'd mention... Along with config macro defs I started extracting all the Config rewrite macros <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig> into a separate library <http://svn.boost.org/trac/boost/browser/sandbox/predef>. -- -- Grafik - Don't Assume Anything -- Redshift Software, Inc. - http://redshift-software.com -- rrivera/acm.org (msn) - grafik/redshift-software.com -- 102708583/icq - grafikrobot/aim,yahoo,skype,efnet,gmail
Rene Rivera wrote:
I thought I'd mention... Along with config macro defs I started extracting all the Config rewrite macros <http://www.crystalclearsoftware.com/cgi-bin/boost_wiki/wiki.pl?BoostConfig> into a separate library <http://svn.boost.org/trac/boost/browser/sandbox/predef>.
If you're rewriting the config macros, one change I'd strongly recommend is a strict separation between macros that are to be defined by the users and macros that are defined in config.hpp. If the documentation says that a macro should be defined by users, then it should not be defined by any of the boost libraries. Joe Gottman
Doug Gregor wrote:
On Apr 4, 2008, at 12:35 PM, Beman Dawes wrote:
In another thread, Doug Gregor wrote:
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. Yes, and some other compilers are also starting to add C++0x features.
Has there been any discussion as to how Boost.Config is going to report availability or not of C++0x features? That would seem to be the first step in what promises to be a long, winding, but *very* interesting and productive path.
I started this discussion a while ago:
http://lists.boost.org/Archives/boost/2006/11/113534.php
Boost 1.35.0 already contains some macros for C++0x features available now, e.g., BOOST_HAS_STATIC_ASSERT (used by boost/static_assert.hpp), BOOST_HAS_VARIADIC_TMPL, BOOST_HAS_RVALUE_REFS, and BOOST_HAS_DECLTYPE. They have their own section of the Boost.Config documentation ("Macros that describe C++0x Features"), and I believe that accurately reflect the capabilities of released compilers.
Ah! Thanks! ...pause while I read that thread... There was some discussion of making the macros negative; BOOST_NO_STATIC_ASSERT or possibly BOOST_NO_0X_STATIC_ASSERT. That seems both better from the maintenance standpoint, and more in line with our current practice. Has a final decision been made on this? --Beman
I'm hoping that my BoostCon tutorial on C++0x and Dan & Joel's Fusion0x tutorial will spur some interest in updating Boost libraries with C++0x support.
- Doug _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Sat, 2008-04-05 at 11:49 -0400, Beman Dawes wrote:
Doug Gregor wrote:
http://lists.boost.org/Archives/boost/2006/11/113534.php
Boost 1.35.0 already contains some macros for C++0x features available now, e.g., BOOST_HAS_STATIC_ASSERT (used by boost/static_assert.hpp), BOOST_HAS_VARIADIC_TMPL, BOOST_HAS_RVALUE_REFS, and BOOST_HAS_DECLTYPE. They have their own section of the Boost.Config documentation ("Macros that describe C++0x Features"), and I believe that accurately reflect the capabilities of released compilers.
Ah! Thanks!
...pause while I read that thread...
There was some discussion of making the macros negative; BOOST_NO_STATIC_ASSERT or possibly BOOST_NO_0X_STATIC_ASSERT. That seems both better from the maintenance standpoint, and more in line with our current practice.
Has a final decision been made on this?
I ended up using BOOST_HAS_*, because C++0x features seemed to be such a long way off back then :) I don't mind either way. It depends on whether we C++0x as our target language (with workarounds for C++98) or whether C++98 is our target language (with extensions for C++0x). I imagine that over the next 5-10 years, our view will shift from the latter to the former... perhaps that means we should just go with BOOST_NO_* now and save ourselves the trouble of changing our minds later. - Doug
Douglas Gregor wrote:
On Sat, 2008-04-05 at 11:49 -0400, Beman Dawes wrote:
Doug Gregor wrote:
http://lists.boost.org/Archives/boost/2006/11/113534.php
Boost 1.35.0 already contains some macros for C++0x features available now, e.g., BOOST_HAS_STATIC_ASSERT (used by boost/static_assert.hpp), BOOST_HAS_VARIADIC_TMPL, BOOST_HAS_RVALUE_REFS, and BOOST_HAS_DECLTYPE. They have their own section of the Boost.Config documentation ("Macros that describe C++0x Features"), and I believe that accurately reflect the capabilities of released compilers. Ah! Thanks!
...pause while I read that thread...
There was some discussion of making the macros negative; BOOST_NO_STATIC_ASSERT or possibly BOOST_NO_0X_STATIC_ASSERT. That seems both better from the maintenance standpoint, and more in line with our current practice.
Has a final decision been made on this?
I ended up using BOOST_HAS_*, because C++0x features seemed to be such a long way off back then :)
Yeah, but getting closer every day:-)
I don't mind either way. It depends on whether we C++0x as our target language (with workarounds for C++98) or whether C++98 is our target language (with extensions for C++0x). I imagine that over the next 5-10 years, our view will shift from the latter to the former... perhaps that means we should just go with BOOST_NO_* now and save ourselves the trouble of changing our minds later.
That's my view, too! Why not plan for the future now? John? --Beman
On Apr 4, 2008, at 10:35 AM, Beman Dawes wrote:
In another thread, Doug Gregor wrote:
The other issue is that it would be great to test gcc-4.3 in C++0x mode (-std=gnu++0x) as well as C++98 mode. Then we can start taking advantage of some of the 0x features. Yes, and some other compilers are also starting to add C++0x features.
Has there been any discussion as to how Boost.Config is going to report availability or not of C++0x features? That would seem to be the first step in what promises to be a long, winding, but *very* interesting and productive path.
As a first step, I setup a nightly build with gcc-4.3.0 with the addition of <cxxflags>-std=gnu++0x. This will run as part of the Sandia-gcc nightly testing with the results listed as: gcc-4.3.0_gnu++0x Test results for this toolset are already on the trunk developer page. -- Noel
participants (6)
-
Beman Dawes -
Doug Gregor -
Douglas Gregor
-
Joe Gottman -
K. Noel Belcourt -
Rene Rivera