9

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!

Improve this question
3
  • 7
    THE solution would probably be to get rid of using namespace std all together. And it could be as simple as doing a global find&replace for every stl element. Commented Jul 4, 2011 at 8:35
  • Right, that would be THE solution, but STL is used so frequently that it would make the code much less readable; perhaps I could consider writing bunch of using std::string; using std::vector; etc declarations in the common header. It is actually not many std:: parts which are used, but they are used very often. Commented Jul 4, 2011 at 8:54
  • 2
    @eudoxos: it takes some getting used to, but the amenability of the code increases so much; Also, I find my self just adding using std::cout; using std::string inside the scope that uses it. That increases readability, especially in less trivial cases (using boost::phoenix::bind or using boost:bind, or using boost::spirit::karma::_1 etc. Removes any ambiguity (to both compiler and programmers) without cluttering up the actual code) Commented Jul 4, 2011 at 9:14

1 Answer 1

Reset to default
3

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.

Improve this answer
Sign up to request clarification or add additional context in comments.

1 Comment

Thanks! I thought it would be more complicated with boost::python. Well, now I use boost::serialization as well, and it does not seem to be as flexible (e.g. this thread suggests to copy & customize what boost::serialization does for boost::shared_ptr.

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.