🔒 Locked

Polymorphic Smart Pointers

Started by Cornstalks Jun 16, 2008 at 11:13 AM 9 replies 2.2k views

Original Post

Jun 16, 2008 at 11:13 AM

Is there a way that I can use polymorphism with smart pointers? More specifically, I have a std::stack of boost::shared_ptr. But when I tried stack.push(new Derived), the compiler gave me the following error:

no matching function for call to `std::stack<boost::shared_ptr<Base>, std::deque<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > > >::push(Derived*)' 
note C:\MinGW\include\c++\3.4.5\bits\stl_stack.h:191 candidates are: void std::stack<_Tp, _Sequence>::push(const typename _Sequence::value_type&) [with _Tp = boost::shared_ptr<Base>, _Sequence = std::deque<boost::shared_ptr<Base>, std::allocator<boost::shared_ptr<Base> > >]

Is there a way to do this?

bubu LV

Jun 16, 2008 at 11:23 AM

Try

stack.push( boost::shared_ptr<Base>( new Derived ) );

vtchill

Jun 16, 2008 at 12:53 PM

Just to add to the above post, it is potentially dangerous to use an unnamed temporary shared_ptr as it has the potential to cause a memory leak.

Something like this would be a better alternative.

boost::shared_ptr<Base> obj(new Derived(/*constructor arguments here*/));stack.push(obj);

fpsgamer

Jun 16, 2008 at 1:06 PM

Quote:
Original post by vtchill
Just to add to the above post, it is potentially dangerous to use an unnamed temporary shared_ptr as it has the potential to cause a memory leak.

Something like this would be a better alternative.

*** Source Snippet Removed ***

Actually it isn't a problem in that case. It would only be a problem if the function accepted multiple arguments.

reference

Cornstalks

Jun 16, 2008 at 1:15 PM

Sweet, thanks to all! I'll try it out. I'm getting to the point where I'm using more and more polymorphic objects and I don't want to worry about memory leaks, so I figured I'd try to use some smart pointers for some extra safety.

[edit]

Works perfectly!

Red Ant

Jun 16, 2008 at 1:43 PM

To get back to the original post, a boost::shared_ptr can definitely be set to point to a Derived. I don't know why the compiler is giving you an error there but this really *should* work IMO.

P.S. Ah never mind ... I should learn to read posts before writing replies.

SiCrane

Jun 16, 2008 at 1:48 PM

Quote:
Original post by Red Ant
I don't know why the compiler is giving you an error there but this really *should* work IMO.

It doesn't because the shared_ptr constructor that takes a single pointer is explicit.

Red Ant

Jun 16, 2008 at 1:54 PM

Yeah sorry ... I hadn't read the post properly before replying. I see now that he was relying on an implicit conversion.

chairthrower

Jun 16, 2008 at 3:14 PM

Quote:
Original post by fpsgamer
Quote:
Original post by vtchill
Just to add to the above post, it is potentially dangerous to use an unnamed temporary shared_ptr as it has the potential to cause a memory leak.

Something like this would be a better alternative.

*** Source Snippet Removed ***

Actually it isn't a problem in that case. It would only be a problem if the function accepted multiple arguments.

reference

youch ... i never considered this. my code has a lot of this kind of thing, (the justification for the init() seperate from the constructor is for dealing with things that interact with shared_from_this())

class A{     typedef shared_ptr< A>  ptr;      static ptr create()      {         ptr p( new A);          p->init();           return p;      }};

is it safe to use in this type of context.

vector< A::ptr>    va; va.push_back( A::create() );

i think its ok - its still a temporary being returned that is used as the const arg of the push_back method, but both the shared pointer and underlying object have been fully constructed and use_count() is always positive even if its only being held by a temporary. what about multiple argument functions . if one of the other arguments methods throws on the constructor - would that still be memory safe ?

fpsgamer

Jun 16, 2008 at 3:33 PM

Quote:
Original post by chairthrower
i think its ok - its still a temporary being returned that is used as the const arg of the push_back method, but both the shared pointer and underlying object have been fully constructed and use_count() is always positive even if its only being held by a temporary. what about multiple argument functions . if one of the other arguments methods throws on the constructor - would that still be memory safe ?

The scenario you illustrated is safe.

The problem (as you've already noted) has to do with when you are dealing with multiple arguments.

Consider this:

void doStuff(boost::shared_ptr(new Foo()), Bar() );

The order in which arguments are evaluated in C++ is undefined. If an exception is thrown at inopportune times you will get a resource leak. Consider this hypothetical argument evaluation order:

(1) exectute 'new Foo()'
(2) construct temporary Bar() object
(3) construct shared_ptr from the value returned by 'new Foo()'

If (2) two throws an exception, stack unwinding will commence and we will loose a handle to the memory allocated in (1).

Thats why you should do this instead:

boost::shared_ptrptr(new Foo()); void doStuff(ptr, Bar() );

If stack unwinding begins as the result of a thrown exception, the shared_ptr will be destroyed and take appropriate care of the heap resource.

Further Reading.

chairthrower

Jun 16, 2008 at 3:49 PM

Thanks very much for the assurances!! and explanation. my body jerked upright when i read these posts - though i now see it discussed if a bit off-handedly in the boost documention. i will make sure to go through both of your references so i understand all implications in the morning when my mind is fresh. thanks again.

Topic Locked

This topic has been locked by a moderator. New replies are not allowed.