Re: [boost] Library TR draft available

From: Jonathan Wakely (cow_at_[hidden])
Date: 2004-11-12 11:00:11

On Fri, Nov 12, 2004 at 04:51:42PM +0200, Peter Dimov wrote:

> Beman Dawes wrote:
> >To insure Boost code works with various TR implementations, some
> >Boost code will want to use the compiler vendor's version of the TR
> >if the TR component required is available, but otherwise will want to use 
> >Boost
> >equivalent code.
> 
> However, some Boost code might want to use the Boost version of the 
> component, even if one is provided in std::tr1;

To avoid ODR violations, would that mean all code that exists in both
Boost and TR1 would have to be in boost::detail, so that e.g.
boost::shared_ptr could be std::tr1::shared_ptr but Boost.SomeThing
could still use boost::detail::shared_ptr if it wanted to ?

Would that _somewhat_ reduce ADL issues, since boost::shared_ptr would
_always_ be declared by a using declaration, for either
std::tr1::shared_ptr or boost::detail::shared_ptr ?

(hmm, I think it might change the symptoms but not really lessen the
problem)

>                                                 and we also need to keep in 
> mind that only some parts of std::tr1 may be missing. TR1-namespace-level 
> global solutions can't work. 

The stdlib/xxx.hpp headers could be made to know which components are
available in which versions of each stdlib and to define the a set of
macros like these:

    BOOST_USE_NATIVE_SHARED_PTR
    BOOST_USE_NATIVE_REGEX
    BOOST_USE_NATIVE_RESULT_OF

Users could explicitly choose either the Boost-provided or native
stdlib-provided implementations by setting BOOST_USE_NATIVE_RESULT_OF
or BOOST_NO_NATIVE_RESULT_OF before the config headers are included.

Figuring out which macros are needed, based on which TR1 implementations
have which bits missing would be a laborious process, but could start
with a baseline assumption that all components are missing and have
bits added as it's shown they're available.

Those are my incomplete thoughts on the matter, for what they're worth,

jon

-- 
"A well-written program is its own heaven
 A poorly written program is its own hell"
	- The Tao of Programming