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