Subject: Re: [boost] [c++0x] Boost implementations of C++0x standard library components?
From: Markus Werle (numerical.simulation_at_[hidden])
Date: 2008-11-05 10:26:30
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
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
b) this is not hindered by setting a MACRO e.g.
> * 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
and I think it was a GoodThing (TM).
Keep the "single point of inclusion" paradigma, please.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk