c++0x std::shared_ptr vs. boost::shared_ptr

I have a c++ code which heavily uses shared_ptr and STL. A common header says

#include<boost/shared_ptr.hpp>
using boost::shared_ptr;  // for shared_ptr
using namespace std;      // for STL

I wanted to switch to c++0x now to make use of the language features, using gcc 4.6 with -std=c++0x. There is however std::shared_ptr now as well, leading to ambiguity for unspecified shared_ptr (boost::shared_ptr vs std::shared_ptr).

When switching to std::shared_ptr instead, like this:

#include<memory>
using namespace std;      // for STL; also imports std::shared_ptr

then I am getting problems with boost::python, which works apprently with boost::shared_ptr only (at least without further fiddling):

/usr/include/boost/python/object/make_ptr_instance.hpp:30:52: error: no matching function for call to 'get_pointer(const std::shared_ptr<Cell>&)'

My question therefore is

if there is a simple solution to resolve the ambiguity between boost::shared_ptr and std::shared_ptr (other than not using c++0x for now), and also
if boost::shared_ptr will eventually be just an alias for std::shared_ptr; that would solve my problem automatically.

Thanks!

You need to the define the freestanding function 'get_pointer' for your shared pointer class for it to work with Boost Python. (Note that this enables you to write your own shared pointer, and still work with Boost Python: this is a conscious design effort to prevent tight coupling of distinct Boost libraries).

You might get that using the boost tr1 compatibility headers, but I haven't tried.

http://boost.cowic.de/rc/pdf/tr1.pdf

When Boost.TR1 is configured to make use of your standard library's native TR1 implementation, then it doesn't do very much: it just includes the appropriate header.

When Boost.TR1 is using the Boost implementation of a particular component, then it includes the appropriate Boost header(s) and imports the necessary declarations in namespace std::tr1 with using declarations. Note that only those declarations that are part of the standard are imported: the implementation is deliberately quite strict about not including any Boost-specific extensions in namespace std::tr1, in order to catch any portability errors in user code. If you really need to use Boost-specific extensions then you should include the Boost headers directly and use the declarations in namespace boost:: instead. Note that this style of implementation is not completely standards-conforming, in particular it is not possible to add user-defined template specializations of TR1 components into namespace std::tr1. There are also one or two Boost libraries that are not yet fully standards conforming, any such non-conformities are documented in the TR1 by subject section. Hopefully, occurrences of non-standard behavior should be extremely rare in practice however.

If you use the standard conforming header includes (in boost/tr1/tr1) then these header names can sometimes conflict with existing standard library headers (for example shared_ptr is added to the existing standard library header rather than it's own header). These headers forward on to your existing standard library header in one of two ways: for gcc it uses #include_next, and for other compilers it uses the macro BOOST_TR1_STD_HEADER(header) (defined in boost/tr1/detail/config.hpp) which evaluates to #include <../include/header>. This should work "straight out the box" for most compilers, but does mean that these headers should never be placed inside a directory called "include" that is already in your compiler's search path.