Boost logo

Boost :

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
<numerical.simulation_at_[hidden]> 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


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk