I mean that something else might be in charge of deleting both objects. E.g. I very often have components that take a pointer to thier parent component, so that they can interact with it. The child will always be deleted by the parent so it’s perfectly safe. But you couldn’t do this with an auto_ptr. I’m sure there are lots of other situations like that too.
I think it’s one of those topics where you could discuss the philosophical niceties of it forever, but in real life it doesn’t cause any problems.
What I WOULD find useful would be some kind of smart pointer that zeros itself when the object it points to gets deleted by something else. Sadly that’s a bit tricky, but it’d be damned useful in Component.cpp, where I’ve had to create the ComponentDeletionWatcher class to do something similar.
P.S. there are many “delete this;” statements. It is pretty obvious why it is evil: http://comp.uark.edu/~vchaudh/old_home_page/repository/c.html. plus one more problem - in case of multiple copies of CRT (specific for Windows app with dll’s linked statically to CRT) you may delete object from wrong heap.[/quote]
good point about the shared DLLs. I’d not thought of that.
But checking through the library, almost all of the times it’s used are safe, because they’re mostly used for temporary objects that were created by code inside the juce library, so the allocator will always be the same.
The only one I spotted that could be a problem was in DialogWindow, if an app creates a subclass with a different allocator and presses the close button. I’ll have a think about that. The rest look fine to me.