Hello, John. Wednesday, November 12, 2008 at 12:41:11 PM you wrote: JM> Sergey Sadovnikov wrote:
Do you mean what there is no way to make boost and TR1 implementations don't conflict each other?
JM> IMO they don't conflict *now*, not unless carelessly polute the global JM> namespace. But, as I already said, some boost examples and boost test cases, and boost documentation pages contains global and local using-declarations. So such 'pollution' conform to the: 1. Boost documentation 2. Boost examples 3. Boost tests 4. Expert opinions (such as Herb Sutter - see "More Exceptional C++", item 40, Namespace Rule #3). JM> BTW Boost.TR1 has the semantics you were looking for: JM> #include <memory> // with boost/tr1/tr1 in the include path JM> std::tr1::shared_ptr<foo> fooptr; // uses vendor supplied shared_ptr if JM> available, otherwise Boost version. Of course. I wonder if all boost headers refer only to the boost/tr1/tr1. But even if you in your projects refer to the boost/tr1/tr1/memory, some boost headers (for example, date_time libraryt) refer directly to the boost/shared_ptr. And you automatically have two different implementation in the two different namespaces.
And, for example, boost::shared_ptr couldn't be transparently replaced by corresponding TR1 class?
JM> The Boost versions of the TR1 components typically have extensions that JM> aren't available in the standard versions. Further some people may prefer JM> to use *the same implementation*, ie the Boost one, across multiple JM> platforms and compilers. IMO the Boost versions should continue to exist JM> and evolve. But another people would prefer std-conformant implementation of this facilities. :) Imagine what you want to use some third-party library which only C++0x-conformant, with you code which use same boost classes. In this case you will have a choice: 1. Use code like this: std::bind(&foo, std::palceholders::_1, std::palceholders::_2 /* etc. */) boost::shared_ptr<SomeType> sp(new SomeType, boost::bind(&SomeType::Release, ::_1); 2. Take a deal with ambiguous name resolution... What you choose? I agree what it would be great if this two implementations will co-exists. But it also will great if this implementations will not conflict each other within global scope. -- Best Regards, Sergey mailto:flex_ferrum@artberg.ru