Simple question here: are you allowed to explicitly delete a boost::shared_ptr
yourself? Should you ever?
Clarifying, I don't mean delete the pointer held by the shared_ptr
. I meant the actual shared_ptr
itself. I know most people suggest to not do it, so I was just wondering if it's OK to explicitly do it.
[Edit: you can
delete
ashared_ptr
if and only if it was created withnew
, same as any other type. I can't think why you'd create ashared_ptr
withnew
, but there's nothing stopping you.]Well, you could write
delete ptr.get();
.Doing so leads almost inevitably to undefined behavior either when the other shared owners use their
shared_ptr
to access the now-deleted object, or the lastshared_ptr
to the object is destroyed, and the object gets deleted again.So no, you shouldn't.
The purpose of
shared_ptr
is to manage an object that no one "person" has the right or responsibility to delete, because there could be others sharing ownership. So you shouldn't ever want to, either.You cannot force its reference count to zero, no.
Think about what would be required for that to work. You would need to go to each place the shared_ptr is used and clear it.
If you did force the shared pointer to delete and set it to NULL, it would be just like a weak_ptr. However, all those places in the code using that shared_ptr are not ready for that and expect to be holding a valid pointer. They have no reason to check for NULL, and so those bits of code would crash.
Your question isn't clear. If you've allocated a
shared_ptr
dynamically then you're certainly allowed todelete
it whenever you want.But if you're asking whether you're allowed to delete whatever object is being managed by the
shared_ptr
, then the answer is ... it depends. Ifshared_ptr::unique
returns true, then callingshared_ptr::reset
will delete the managed object. However, ifshared_ptr::unique
returns false, it means there are more than oneshared_ptr
s sharing ownership of that object. In this case a call toreset
will only result in the reference count being decremented by 1, actual deletion of the object will take place when the lastshared_ptr
managing that object either goes out of scope or is itselfreset
.EDIT:
After your edit, it seems you are asking about deleting a dynamically allocated
shared_ptr
. Something like this:This is allowed and will work as expected, although it would be an unusual use case. The only caveat is that if in between the allocation and deletion of
sp
you create anothershared_ptr
that shares ownership of the object, deletingsp
will not result in deletion of the object, that will only happen when the reference count for the object goes to 0.Expliticly deleting comes in handy in some (very?) rare cases.
In addition to explicitly deleting, sometimes you HAVE to explicitly destruct a shared pointer when you are 'deleting' it!
Things can get weird when interfacing with C code, passing a shared_ptr as an opaque value.
For example I have the following for passing objects to and from the Lua scripting language which is written in C. (www.lua.org)
So thats a shared_ptr in some malloc'd memory. The reverse is this... (setup to be called just before Lua garbage collects an object and 'free's it).
If you want to simulate the count decrement, you can do it manually on the heap like so:
Or on the stack using
std::shared_ptr::reset()
like so:But it's not that useful.