Re: [boost] [c++0x] Boost implementations of C++0x standard library components?

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
> <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