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

I have just installed the current version of the gcc compiler on an Apple XServe/darwin platform, and then recompiled boost using the new gcc. I have found that it is still necessary to use the 'using darwin' option. However, the new gcc does not support the -no-cpp-precomp option and I had to modify line 332 of darwin.jam before it could compile. It looks as if this is only needed for old Apple compilers, and may well be removed from the new Apple compiler http://www.vtk.org/Bug/view.php?id=6267 Perhaps darwin.jam could be changed to make its use conditional on the release of the compiler? Nigel

John Maddock <john <at> johnmaddock.co.uk> writes:

...

Or are we going to run into trouble because another std header might include the compiler's tr1 stuff again?

Yes, for example there are TR1 components in existing C++ std lib headers such as <utility> <cmath> etc.

So there's no mechanism by which we can avoid including the vendors version if it's available.

[Still not giving up] What we need then is the possiblity to use the boost tr1 components from namespace boost::tr1, e.g. boost::tr1::tuple<...> // behaves like std::tr1::truple. vs. boost::tuple<...> // does not behave like std::tr1::tuple Is this feasible? Markus

...

[Still not giving up] What we need then is the possiblity to use the boost tr1 components from namespace boost::tr1, e.g. boost::tr1::tuple<...> // behaves like std::tr1::truple. vs. boost::tuple<...> // does not behave like std::tr1::tuple

Is this feasible?

How is this better than boost::tuple directly?

That's the thing, I don't think it is: remember that Boost.TR1 is really just a bunch of using-directives that pull the boost:: code into std::tr1::, the only difference really is that the boost:: namespace may contain some additional features that aren't in the TR. But if that's an issue, you could just as easily cut and paste the using directives into your own namespace. John.