John Maddock wrote:
That's the intention
Okay, so far so good.
BOOST_HAS_TR1 tells the lib to use the platform's native TR1 implementation for *everything*, if you want to just use the native support for *something* then you have to turn it on on a case by case basis for each component where you want to use the platform-supplied version.
Now I'm confused, because this doesn't seem consistent with the above. This makes it sound like I need to know which TR1 components are supported by my compiler/library and I need to explicitly enable them. Is that really the case?
VC8: define nothing there's no native TR1 support, unless you've bought the Dinkumware add-on in which case define BOOST_HAS_TR1 to make use of it.
Which is consistent with the "explicitly specify what your compiler/library support" idea above. Unfortunately :-(
gcc: nothing if you're happy with the Boost versions, BOOST_HAS_GCC_TR1 if you want to use the gcc-supplied versions. It's possible that BOOST_HAS_GCC_TR1 is somewhat out of date, I don't recall now which gcc version I tested with, but 4.2 probably has more TR1 support than it currently enables.
Which means that the macro doesn't mean "turn on whatever gcc TR1 support you have," it means "turn on the following TR1 components that I, the macro writer, believe are supported by gcc." Again, consistent with the above. And, again, unfortunately :-( I'd hoped that Boost.TR1 would magically figure out what TR1 stuff was available from my compiler/library and use that by default, falling back on Boost functionality only when necessary. Apparently that is not the way it works :-( Scott