Search code examples
c++boostshared-ptr

How to convert an object instance to shared_ptr instance


Suppose I had two shared_ptr types such as

boost::shared_ptr<ObjA> sptrA;
boost::shared_ptr<ObjB> sptrB;

Now suppose that sptrA->SomeMethod() returned a simple ObjB type (not a shared ptr). Is it possible for me to store that type somehow in sptrB ? So that I could do something like this so that the returned type instance is automatically converted to boost_shared ptr

sptrB = sptrA->SomeMethod(); 

I asked this question just of curiosity and whether it is possible or not ?


Solution

  • The most standard way of creating boost:shared_ptr objects is to use the make_shared function provided by Boost:

    #include <boost/shared_ptr.hpp>
    #include <boost/make_shared.hpp>
    
    struct A {};
    
    A generator() {
      return A();
    }
    
    int main()
    {
      using namespace boost;
      shared_ptr<A> p = make_shared<A>(generator());
      return 0;
    }
    

    Since the generator() function returns an A object by value, the syntax above implies that new is invoked with the copy contructor of A, and the resulting pointer is wrapped in a shared-pointer object. In other words, make_shared doesn't quite perform a conversion to shared pointer; instead, it creates a copy of the object on the heap and provides memory management for that. This may or may not be what you need.


    Note that this is equivalent to what std::make_shared does for std::shared_ptr in C++11.


    One way to provide the convenient syntax you mentioned in your question is to define a conversion operator to shared_ptr<A> for A:

    struct A {
      operator boost::shared_ptr<A>() {
        return boost::make_shared<A>(*this);
      }
    };
    

    Then you can use it as follows:

    shared_ptr<A> p = generate();
    

    This will automatically "convert" the object returned by the function. Again, conversion here really means heap allocation, copying and wrapping in a shared pointer. Therefore, I am not really sure if I'd recommend defining such a convenience conversion operator. It makes the syntax very convenient, but it, as all implicit conversion operators, may also mean that you implicitly cause these "conversions" to happen in places you didn't expect.