[c++0x] Boost implementations of C++0x standard library components?
I want to submit an improved timer to Boost. I'd like it to use the C++0x standard library's <chrono> and <ratio> headers. Because it will be many years before such C++0x are universally available, I think Boost should include an implementation of these libraries. Howard Hinnant has kindly contributed his demo implementation of <chrono> and <ratio> as a starting point, so the hard stuff is already done. I'm starting to boostify his code. That brings up questions of header and namespace names. Presumably what we do with these two small headers will set the pattern for any other C++0x standard library headers we include in Boost. Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost: * Such libraries go through the regular formal review process, although it will need to be adjusted a bit since the interface is already known and frozen. * C++0x standard library header naming convention is followed. Thus these will be named <chrono> and <ratio> rather than <chrono.hpp> and <ratio.hpp>. * C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono. * Directory structure: boost-root boost c++0x // <ratio>, <chrono>, and other c++0x std lib headers go here ... libs c++0x chrono build doc src // if needed test ratio build doc src // if needed test ... This allows a user to refer to say the ratio header as <boost/c++/ratio>, <c++/ratio>, or just plain <ratio>. The user would have to provide an additional include path of boost-root/boost or boost-root/boost/c++0x for the second and third usages to work. Comments? --Beman
Beman Dawes <bdawes <at> acm.org> writes:
Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost:
* Such libraries go through the regular formal review process, although it will need to be adjusted a bit since the interface is already known and frozen.
* C++0x standard library header naming convention is followed. Thus these will be named <chrono> and <ratio> rather than <chrono.hpp> and <ratio.hpp>.
I' d prefer a similar approach to the one taken for tr1: #include <boost/c++0x/chrono.hpp> will automagically use the version the compiler provides if a) it is available and b) this is not hindered by setting a MACRO e.g. BOOST_IGNORE_COMPILER_CPP0X_BUT_USE_BOOST_CPP0X
* C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono.
Agreed, but like in tr1 both versions could be available, depending on which header I include, like for boost::function vs. tr1::function Example: For tr1 I found that the boost implementation of function has a feature missing in tr1, namely setting the maximum number of arguments higher than 10, so for one translation unit I use boost/function.hpp directly. I am forced to do so since tr1 does not offer this feature in a portable manner (which is - IMHO - a pity, like the template nesting depth of 18, but that only a s side remark)
* Directory structure: [...] This allows a user to refer to say the ratio header as <boost/c++/ratio>, <c++/ratio>, or just plain <ratio>. The user would have to provide an additional include path of boost-root/boost or boost-root/boost/c++0x for the second and third usages to work.
The fiddling with compiler settings always brought me headache and unbearable pain. The boost approach so far was #include <boost/some/path/to/header.hpp> and I think it was a GoodThing (TM). Keep the "single point of inclusion" paradigma, please. best regards, Markus
On Wed, Nov 05, 2008 at 03:26:30PM +0000, Markus Werle wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost:
I really like Beman's proposal, especially because ...
I' d prefer a similar approach to the one taken for tr1: #include <boost/c++0x/chrono.hpp> will automagically use the version the compiler provides if a) it is available and b) this is not hindered by setting a MACRO e.g. BOOST_IGNORE_COMPILER_CPP0X_BUT_USE_BOOST_CPP0X
... this would make my own code even more depending on Boost. I even need some Boost header files for tr1 if my compiler has tr1 support. Using Beman's suggestion I only have to write a little autoconf macro.
* C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono.
Agreed, but like in tr1 both versions could be available, depending on which header I include, like for boost::function vs. tr1::function
Right ... :-( Jens
On Wed, Nov 5, 2008 at 10:26 AM, Markus Werle <numerical.simulation@web.de> wrote:
Beman Dawes <bdawes <at> acm.org> writes:
Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost:
* Such libraries go through the regular formal review process, although it will need to be adjusted a bit since the interface is already known and frozen.
* C++0x standard library header naming convention is followed. Thus these will be named <chrono> and <ratio> rather than <chrono.hpp> and <ratio.hpp>.
I' d prefer a similar approach to the one taken for tr1: #include <boost/c++0x/chrono.hpp> will automagically use the version the compiler provides if a) it is available and b) this is not hindered by setting a MACRO e.g. BOOST_IGNORE_COMPILER_CPP0X_BUT_USE_BOOST_CPP0X
OK, I'll look at doing that.
* C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono.
Agreed, but like in tr1 both versions could be available, depending on which header I include, like for boost::function vs. tr1::function Example: For tr1 I found that the boost implementation of function has a feature missing in tr1, namely setting the maximum number of arguments higher than 10, so for one translation unit I use boost/function.hpp directly. I am forced to do so since tr1 does not offer this feature in a portable manner (which is - IMHO - a pity, like the template nesting depth of 18, but that only a s side remark)
Good points.
* Directory structure: [...] This allows a user to refer to say the ratio header as <boost/c++/ratio>, <c++/ratio>, or just plain <ratio>. The user would have to provide an additional include path of boost-root/boost or boost-root/boost/c++0x for the second and third usages to work.
The fiddling with compiler settings always brought me headache and unbearable pain. The boost approach so far was #include <boost/some/path/to/header.hpp> and I think it was a GoodThing (TM). Keep the "single point of inclusion" paradigma, please.
I'll try. Thanks for the comments, --Beman
Beman Dawes wrote:
Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost:
* Such libraries go through the regular formal review process, although it will need to be adjusted a bit since the interface is already known and frozen.
* C++0x standard library header naming convention is followed. Thus these will be named <chrono> and <ratio> rather than <chrono.hpp> and <ratio.hpp>.
* C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono.
Why do something similar to what we did with the TR1 interfaces and have: <boost/chrono.hpp> (rather like boost/stdint.hpp actually) or <boost/c++0x/chrono.hpp> with code in namepsace boost, and then add a thin wrapper <chono> that imports code into namespace std::chrono.
* Directory structure:
boost-root boost c++0x // <ratio>, <chrono>, and other c++0x std lib headers go here ... libs c++0x chrono build doc src // if needed test ratio build doc src // if needed test ...
Nod. John.
This allows a user to refer to say the ratio header as <boost/c++/ratio>, <c++/ratio>, or just plain <ratio>. The user would have to provide an additional include path of boost-root/boost or boost-root/boost/c++0x for the second and third usages to work.
Comments?
--Beman _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
No virus found in this incoming message. Checked by AVG - http://www.avg.com Version: 8.0.175 / Virus Database: 270.8.6/1769 - Release Date: 05/11/2008 07:17
On Wed, Nov 5, 2008 at 11:33 AM, John Maddock <john@johnmaddock.co.uk> wrote:
Beman Dawes wrote:
Here is a strawman proposal for how we organize C++0x standard library components we choose to add to Boost:
* Such libraries go through the regular formal review process, although it will need to be adjusted a bit since the interface is already known and frozen.
* C++0x standard library header naming convention is followed. Thus these will be named <chrono> and <ratio> rather than <chrono.hpp> and <ratio.hpp>.
* C++0x standard library namespaces are used. Thus namespace std and std::chrono rather than boost and boost::chrono.
Why do something similar to what we did with the TR1 interfaces and have:
<boost/chrono.hpp>
(rather like boost/stdint.hpp actually)
or
<boost/c++0x/chrono.hpp>
with code in namepsace boost, and then add a thin wrapper <chono> that imports code into namespace std::chrono.
OK, let me take a look at that approach. Thanks for the comments, --Beman
participants (4)
-
Beman Dawes -
Jens Seidel -
John Maddock -
Markus Werle