Subject: Re: [boost] [c++0x] Boost implementations of C++0x standard library components?
From: Beman Dawes (bdawes_at_[hidden])
Date: 2008-11-05 17:30:29
On Wed, Nov 5, 2008 at 10:26 AM, Markus Werle
> 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.
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)
>> * 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.
Thanks for the comments,
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk