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.