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!

Trevor Boyd Smith
  • 18,164
  • 32
  • 127
  • 177
eudoxos
  • 18,545
  • 10
  • 61
  • 110
  • 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. – stijn Jul 04 '11 at 08: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. – eudoxos Jul 04 '11 at 08: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) – sehe Jul 04 '11 at 09:14

1 Answers1

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.

sehe
  • 374,641
  • 47
  • 450
  • 633
  • 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](http://stackoverflow.com/questions/4094604/boost-serialization-serialize-stdtr1shared-ptr) suggests to copy & customize what boost::serialization does for boost::shared_ptr. – eudoxos Jul 04 '11 at 08:43