Re: [Boost-users] [TR1] Configuration macros

From: John Maddock (john_at_[hidden])
Date: 2007-05-31 04:09:47

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.