Smart Pointers and 'delete'
Author
I have written by own smart pointer class which seems to work quite well, but it seems smart pointers should never have 'delete' called on them (unless they are allocated with new), as this seems to delete the object that the pointer is pointer to (conversion?).
Is there a way to stop or trap delete being called on the smart pointer? How do other libraries stop people doing this?
Thanks
If you don't provide an implicit conversion to the underlying pointer type the statement delete smartPointer; becomes a compile error. And it's great that you've written your own smart pointer. Now that you've learnt how to write one, throw it away and use the (soon to be standard) boost smart pointers.
Enigma
Enigma
Author
Quote:Original post by Enigma
If you don't provide an implicit conversion to the underlying pointer type the statement delete smartPointer; becomes a compile error. And it's great that you've written your own smart pointer. Now that you've learnt how to write one, throw it away and use the (soon to be standard) boost smart pointers.
Enigma
I'd like to finish my implementation first. I do have a conversion function, so I am not getting a compile error, but I am assuming that it is converting to a true pointer of the underlying type, thus deleting the object. Surely this can't happen if there are other references, so how do I stop it? Do I need to put assert code into the base object's destructor to assert if the reference count is not zero?
You need to not have a conversion operator. When the compiler sees the statement delete pointer; it first checks to see if pointer is of type (anything) *. If not it looks to see if it can convert pointer to an (anything) *. If your smart pointer class provides a operator TYPE *() and/or operator TYPE const *() const then the compiler will apply this conversion, making the original statement equivalent to delete (pointer.operator TYPE *()) and will therefore delete the returned pointer. The only way to disallow this is to not provide the conversion operator but instead provide a named member function to access the raw pointer (i.e. get()).
Enigma
Enigma
I usually never explicitly delete objects contained in smart pointer. I use smart pointers to avoid having to think about deleting objects.
But in the case where I need to control the explicity deletion of an object, I simply assign NULL or 0 to the smart pointer. The overloaded assignment operator handles the deletion internally. It also makes code more generic as it works the same for refcounted smart pointers.
But in the case where I need to control the explicity deletion of an object, I simply assign NULL or 0 to the smart pointer. The overloaded assignment operator handles the deletion internally. It also makes code more generic as it works the same for refcounted smart pointers.
Author
Quote:Original post by Blaster
I usually never explicitly delete objects contained in smart pointer. I use smart pointers to avoid having to think about deleting objects.
But in the case where I need to control the explicity deletion of an object, I simply assign NULL or 0 to the smart pointer. The overloaded assignment operator handles the deletion internally. It also makes code more generic as it works the same for refcounted smart pointers.
I hear what you are saying, but when you are dealing with both smart pointers and regular pointers it's easy to accidentally have a delete on a smart pointer. Would be nice if there was a way to trap this to avoid memory errors.
make the deconstructor private. stops delete being a valid statement( the compiler will complain), if i remember correctly
I would have recommended making operator delete() private in the smart pointer but that would simply prevent deleting a smartpointer*, not calling delete with a smartpointer&.
A private destructor would not allow local allocation or making the object a member.
I am clueless sorry.
A private destructor would not allow local allocation or making the object a member.
I am clueless sorry.
Making the destructor private also stops you from using the smart pointer at all.
IMHO don't worry about it. It's standard practice that you don't call delete on smart pointers. If you're really that concerned about it then maybe you can provide your own operator delete for the smart pointer class.
IMHO don't worry about it. It's standard practice that you don't call delete on smart pointers. If you're really that concerned about it then maybe you can provide your own operator delete for the smart pointer class.
Author
Quote:Original post by Anon Mike
Making the destructor private also stops you from using the smart pointer at all.
IMHO don't worry about it. It's standard practice that you don't call delete on smart pointers. If you're really that concerned about it then maybe you can provide your own operator delete for the smart pointer class.
Do the base destructors always get called for sub-classes when the destructor is virtual, or do I need to call it myself from the sub-class?
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
