[TR1] Configuration macros
I'm having trouble understanding the information at http://www.boost.org/doc/html/boost_tr1/config.html, and having already spent a fair amount of time running test programs and pouring over the output of the preprocessor for various compilers, I'm hoping that somebody in the know can just explain things to me. My goal is simple: use Boost.TR1 such that if my compiler ships with a library with support for whatever TR1 component I want to use, I'll get that native support. But if the library that ships with the compiler lacks support for the TR1 component I need, I want to fall back on the Boost implementation, if there is one. And I want to uniformly refer to TR1 components as if they are in the namespace std::tr1. My reading of the above-referenced page leads me to believe that this is the behavior I'm supposed to get by default. And it's consistent with the tests I've performed using VC8 and g++ 4.1. But then I read this:
The configuration macros used by each TR1 component are documented in each library section (and all together in the Boost.Config documentation), but defining BOOST_HAS_TR1 will turn on native TR1 support for everything (if your standard library has it), which can act as a convenient shortcut.
This kind of suggests that I should define BOOST_HAS_TR1. Should I? So far I have not. And then I read this:
Boost.TR1 does not currently enable gcc's native TR1 implementation as this is currently in an early stage of development. However, you may choose to do so by defining BOOST_HAS_GCC_TR1.
This pretty clearly suggests that I should define BOOST_HAS_GCC_TR1. Should I? So far, I have. I've also found that unless I define it like this,
#ifdef __GNUC__ #define BOOST_HAS_GCC_TR1 #endif
compilation with VC8 fails, which I find kind of strange. Here's an error I get:
D:\C++\Boost\Current\boost/tr1/type_traits.hpp(11): fatal error C1083: Cannot open include file: 'type_traits': No such file or dire ctory
Why should defining BOOST_HAS_GCC_TR1 have any effect on a VC8 compilation? All clarification about the correct settings of TR1 configuration macros for at least VC8 and g++ 4.1 would be much appreciated. Thanks, Scott
Scott Meyers wrote:
My goal is simple: use Boost.TR1 such that if my compiler ships with a library with support for whatever TR1 component I want to use, I'll get that native support. But if the library that ships with the compiler lacks support for the TR1 component I need, I want to fall back on the Boost implementation, if there is one. And I want to uniformly refer to TR1 components as if they are in the namespace std::tr1.
That's the intention: there may be issues with components from mixed sources not interacting well with each other, but try it and see :-)
My reading of the above-referenced page leads me to believe that this is the behavior I'm supposed to get by default. And it's consistent with the tests I've performed using VC8 and g++ 4.1. But then I read this:
The configuration macros used by each TR1 component are documented in each library section (and all together in the Boost.Config documentation), but defining BOOST_HAS_TR1 will turn on native TR1 support for everything (if your standard library has it), which can act as a convenient shortcut.
This kind of suggests that I should define BOOST_HAS_TR1. Should I? So far I have not.
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. In time we may get smarter at auto-configuring this, but TR1 support is too thin on the ground at present...
And then I read this:
Boost.TR1 does not currently enable gcc's native TR1 implementation as this is currently in an early stage of development. However, you may choose to do so by defining BOOST_HAS_GCC_TR1.
This pretty clearly suggests that I should define BOOST_HAS_GCC_TR1. Should I? So far, I have. I've also found that unless I define it like this,
#ifdef __GNUC__ #define BOOST_HAS_GCC_TR1 #endif
Correct, I'll fix that so it only effect's gcc.
compilation with VC8 fails, which I find kind of strange. Here's an error I get:
D:\C++\Boost\Current\boost/tr1/type_traits.hpp(11): fatal error C1083: Cannot open include file: 'type_traits': No such file or dire ctory
Why should defining BOOST_HAS_GCC_TR1 have any effect on a VC8 compilation?
All clarification about the correct settings of TR1 configuration macros for at least VC8 and g++ 4.1 would be much appreciated.
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. 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. HTH, John.
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
Scott Meyers wrote:
Which is consistent with the "explicitly specify what your compiler/library support" idea above. Unfortunately :-(
Right, but please remember that there is only one compiler that ships with *any* TR1 support at all - gcc - and that was still in the very early stages of development when Boost.TR1 was developed. Given time it'll get smarter and "learn" about more compilers/platforms as they release TR1 support - if they do.
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 :-(
Not yet :-( As I say, it'll learn. John.
John Maddock wrote:
Right, but please remember that there is only one compiler that ships with *any* TR1 support at all - gcc - and that was still in the very early stages of development when Boost.TR1 was developed.
My understanding is that Metrowerks' compiler also ships with some TR1 support and has for a few years now (see e.g., http://www.ddj.com/dept/cpp/184406110 ), though I believe Metrowerks is now part of Freescale Semiconductor and is focusing on the embedded market. I don't know if they still produce a general-purpose C++ compiler. Scott
At 8:43 AM -0700 6/1/07, Scott Meyers wrote:
John Maddock wrote:
Right, but please remember that there is only one compiler that ships with *any* TR1 support at all - gcc - and that was still in the very early stages of development when Boost.TR1 was developed.
My understanding is that Metrowerks' compiler also ships with some TR1 support and has for a few years now (see e.g., http://www.ddj.com/dept/cpp/184406110 ), though I believe Metrowerks is now part of Freescale Semiconductor and is focusing on the embedded market. I don't know if they still produce a general-purpose C++ compiler.
If by "general purpose C++ compiler" you mean "targets Mac OS, Windows, or Linux" then AFAIK the answer is no. -- -- Marshall Marshall Clow Idio Software mailto:marshall@idio.com It is by caffeine alone I set my mind in motion. It is by the beans of Java that thoughts acquire speed, the hands acquire shaking, the shaking becomes a warning. It is by caffeine alone I set my mind in motion.
participants (3)
-
John Maddock -
Marshall Clow -
Scott Meyers