John Maddock <john <at> johnmaddock.co.uk> writes:
I'd like to #include <boost/tr1/*.hpp> while at the same time state that I am *not* interested in the compiler's TR1 implementation (vc9 ...)
Any MACRO BOST_HAS_NO_TR1 I missed? The opposite (BOOST_HAS_TR1) exists.
Unfortunately you can't do that: the std::tr1 namespace has already been polluted by the vendors implementation so we can't add ours in there as well.
I have not included the TR1 headers of my compiler, so the pollution could be avoided. I expect boost/tr1/*.hpp to include the corresponding compiler's header only if configured in that way.
You can of course use boost::whatever directly, rather than std::tr1::whatever.
Boost::whatevers are quite different from their TR1 sisters. (missing operator<< etc.) So I am really interested in the implications of those differences and want to have my code use std::* wherever possible. Boost contains a TR1 implementation, but unfortunately I face difficulties to enfiorce its usage. This I find odd. Can we have the inclusion decision mechanisms be changed to something similar to: #if (defined(BOOST_HAS_TR1_TUPLE) && !defined(BOOST_USE_BOOST_TR1_IMPL)) # ifdef BOOST_HAS_INCLUDE_NEXT # include_next BOOST_TR1_HEADER(tuple) # else # include <boost/tr1/detail/config_all.hpp> # include BOOST_TR1_STD_HEADER(BOOST_TR1_PATH(tuple)) # endif #else ... Or are we going to run into trouble because another std header might include the compiler's tr1 stuff again? Markus