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