Re: [boost] Library TR draft available

From: John Maddock (john_at_[hidden])
Date: 2004-11-13 06:01:46

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

Personally I would rather not see Boost components replaced with std::tr1 
versions, I would rather that:

boost::something always gave you the Boost version, for reasons of 
portability, extra features or just personal preference some users may 
prefer this.
std::tr1 gives you the tr1 version if it's available, otherwise the Boost 
version.

In other words I'm suggesting a tr1 subdirectory in the Boost tree 
containing the tr1 headers, which would either be wrappers to the std or 
Boost versions as required.

Just another 2c...

John.