Re: [boost] boost and vendor's TR1 implementations

Subject: Re: [boost] boost and vendor's TR1 implementations
From: Michael Marcin (mike.marcin_at_[hidden])
Date: 2008-11-11 14:43:38

Sergey Sadovnikov wrote:
> Hello All,
> 
> Today there is at least two implementations of TR1 library extensions shipped
> with compilers. I mean VS 2008 SP1 and gcc 4.3.x STL. Because of boost
> has it's own implementation of TR1 there is some problems with
> migrating code to this compilers. For example:
> 
> 1. There is many ambiguous names if both boost and std::tr1 exposed
> into global namespace.
> 2. boost::transform_iterator knows nothing about std::tr1::bind
> shipped with VS2008 compiler.
> 
> I think what first problem is very serious. I sure what there is a
> lot of code what exposed 'boost' namespace into global scope. Some
> of boost test cases has such directives (tests for 'function',
> 'tokenizer', 'string algo' libraries for example).
> When developers will start to expose 'std::tr1' namespace into global
> scope they will be encountered many problems with compilation.
> I think what it will be good idea to hide boost implementation of
> TR1 classes when this classes shipped with compiler. For example:
> 
> //...
> #ifdef _HAS_TR1
> #include <memory>
> 
> namespace boost
> {
>    using std::tr1::shared_ptr;
>    //... other usings
> }
> #else
> // rest of the shared_ptr.hpp
> #endif
> 

Many of the boost libraries have evolved beyond their TR1 counter parts. 
Boost's shared_ptr is a good example of this. I primarily use VC9 SP1 
which has a tr1 implementation but I use features of boost::shared_ptr 
that std::tr1::shared_ptr doesn't have.

-- 
Michael Marcin