Delete memory from inside a class
Author
Now it's more a matter of taste since this behaviour is hidden from the one that uses the code. But I would agree that a new would somwhere in the open be followed by a delete and not hidden.
The reason we are suggesting changing how you are doing it, is because it is much safer and takes advantage of RAII.
With smart pointers, you can guarentee the destructor is called when there are no longer any references to your object. And thus can also guarentee the children's deletion, assuming nothing else has a smart pointer to them as well.
Since you are deleting the object internally, you might not know what is still trying to use that pointer. Internally it might be deleted, but externally there could be other code that don't realize the object has been deleted and will still try and access the object/memory like it was still there. The smart pointers help prevent this from happening.
With smart pointers, you can guarentee the destructor is called when there are no longer any references to your object. And thus can also guarentee the children's deletion, assuming nothing else has a smart pointer to them as well.
Since you are deleting the object internally, you might not know what is still trying to use that pointer. Internally it might be deleted, but externally there could be other code that don't realize the object has been deleted and will still try and access the object/memory like it was still there. The smart pointers help prevent this from happening.
Quote:Original post by rikardo
Now it's more a matter of taste since this behaviour is hidden from the one that uses the code. But I would agree that a new would somwhere in the open be followed by a delete and not hidden.
It is clearer to the average programmer what is going on when you explicitly use delete. The question is, what advantages does wrapping this behaviour in a function have? A disadvantage is that it can leak memory if one uses naked delete instead of the "destroy" function.
Quote:Original post by rikardo
Instead the manager has a list with all the frames and when the close button is clicked it gets a message that it should DESTROY the frame. When it does it just calls the window's destroy method and removes it from the list.
The problem is that you need to guarantee that nobody holds the reference to your just destroyed window. This is non-trivial.
One way is to use boost's shared_ptr and enable_shared_from_this. It may however leave dangling pointers.
Alternative can use deferred destruction. Something like this:
...if (window -> closeButtonIsClicked()) { manager.mark_for_destruction(this); }...while (1) { manager.update(); manager.cleanup();}cleanup() is implemented something like this:
for (every object d in marked_for_destruction) for (every object o in UI) o.remove_object(d); delete d;}For this reason one would need to make pointer to UI objects some special handle which discourages or tries to prevent code referencing it, at which point smart pointers are a much more robust solution anyway.
Any particular reason for rolling your own UI framework instead of existing ones? Or at least reusing existing architectures (MVC + observers)?
Quote:Original post by GrafalgarThe practice of deleting an object from inside its own member function is at the heart of all intrusive reference-counting schemes, e.g. the one used in COM.Quote:Original post by rikardo
Instead the manager has a list with all the frames and when the close button is clicked it gets a message that it should DESTROY the frame. When it does it just calls the window's destroy method and removes it from the list.
Well, let me ask you this - what would you gain from calling "obj->destroy()" instead of "delete obj" and still provide the same functionality?
Putting it differently: if I got a hold of your code and removed the "destroy()" function completely and replaced all references to that function with "delete ptr;" .. what would be lost/broken in the process?
Quote:Original post by iMalc
The practice of deleting an object from inside its own member function is at the heart of all intrusive reference-counting schemes, e.g. the one used in COM.
Sure, but not in his case. Since he's not doing any reference counting (from what I can tell), deleting the memory internally (as opposed to simply calling "delete ptr") does not allow him to solve any particular issues that would otherwise be much more difficult/error-prone if using only "delete."
[Edited by - Grafalgar on December 23, 2009 12:11:30 PM]
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
