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
>> >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
>> and we also need to keep
>> 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:
> 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
std::tr1 gives you the tr1 version if it's available, otherwise the Boost
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...
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk