C ++ 0x std :: shared_ptr vs boost :: shared_ptr

Question

I have C ++ code that uses shared_ptr and STL heavily. General heading says

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

Now I wanted to switch to C ++ 0x to use language functions using gcc 4.6 with -std=c++0x . However, there is also std::shared_ptr , which leads to ambiguity for the undefined shared_ptr ( boost::shared_ptr vs std::shared_ptr ).

When switching to std::shared_ptr instead:

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

then I have problems with boost::python , which only works with boost::shared_ptr (at least without further messing around):

 /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>&)' 

Therefore my question

• if there is a simple solution to eliminate the ambiguity between boost::shared_ptr and std::shared_ptr (other than using C ++ 0x), and also
• if boost::shared_ptr will ultimately be just an alias for std::shared_ptr ; which will automatically solve my problem.

Thanks!

Answer 1

You need to define a free function 'get_pointer' for your generic pointer class so that it works with Python Boost. (Note that this allows you to write your own generic pointer and still work with Python Boost: this is a conscious design work to prevent hard linking of individual Boost libraries).

You can get this using boost tr1 compatibility headers, but I haven't tried it.

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

When Boost.TR1 is configured to use the standard TR1 implementation of the standard library, then this is not very much: it simply includes the corresponding header.

When Boost.TR1 uses the Boost implementation for a particular component, it includes the corresponding Boost header and imports the necessary declarations in the std :: tr1 namespace using declarations. Please note that only those declarations that are part of the standard are imported: the implementation is intentionally quite strictly related to not including extensions specific to Boost 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 Boost headers directly and use declarations in the boost :: namespace instead. Please note that this implementation style is not fully compliant with the standards; in particular, it is not possible to add custom template specializations TR1 to the std :: tr1 namespace. There is also one or two Boost libraries that are not yet fully compliant with the standards; any such inconsistencies are documented in TR1 in the thematic section. We hope that cases of abnormal behavior should however, in practice this will be extremely rare.

If you use the standard appropriate header, including (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 its own header). These headers are passed 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 “out of the box” for most compilers, but that means that these headers should never be placed in a directory called “include” that is already in your compiler search path.