Boost logo

Boost Users :

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.


Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net