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