The Design of Software (CLOSED)

A public forum for discussing the design of software, from the user interface to the code architecture. Now closed.

The "Design of Software" discussion group has been merged with the main Joel on Software discussion group.

The archives will remain online indefinitely.

Is there a way to prevent deltion of an object?

Suppose a client code receives a pointer to an object,
is there a method to prevent the client from deleting that object?
Dale Lawrence
Thursday, September 07, 2006
 
 
Declare the destructor as protected.
Christopher Wells Send private email
Thursday, September 07, 2006
 
 
Use a smartpointer so the object so it want get destroyed as long as someone is referencing it.
Mellowman Send private email
Thursday, September 07, 2006
 
 
Given a smart pointer, can a client call the destructor explicity, like ...

smartFoo->~Foo();

... or ...

delete &(*smartFoo);

?
Christopher Wells Send private email
Thursday, September 07, 2006
 
 
Basically, a smart pointer 'owns' the resource it's managing, so a simple answer is 'no you can't do that' as it's non-sensical.

However, there's nothing to stop you declaring a method on a smart pointer that deletes the underlying object. Or, of course, you could allocate the smart pointer itself on the heap, and then deleting the pointer would automagically delete the underlying object. But that would be silly ;)
James
Thursday, September 07, 2006
 
 
Make operator delete private, or just document it and don't worry.
bmm6o Send private email
Thursday, September 07, 2006
 
 
"Given a smart pointer, can a client call the destructor explicity"

If you use standard smart pointers they could get the raw pointer that the smart pointer wraps and delete it manually. However, if they're that stupid perhaps they deserve what they get. :)
sloop
Thursday, September 07, 2006
 
 
"Or, of course, you could allocate the smart pointer itself on the heap, and then deleting the pointer would automagically delete the underlying object. But that would be silly ;)"

It doesn't matter if the smart pointer is allocated on the heap. Deleting it is the same as letting a smart pointer on the stack go out of scope, there's no difference in how the underlying pointer would be deleted.
sloop
Thursday, September 07, 2006
 
 
I assume this is C++...

The answer is, in general, not without crashing.

The reason is because objects on the stack are automatically deleted.  Preventing them from being deleted, requires that you can un-unwind the stack, which is really, really, really, tricky.

The other reason is that the framework code which performs the actual destruction, can't fail (and throwing exceptions is Really Bad) and has no idea what to do with a failure code (it just keeps right on deleting).

The best way is to call a Close-type method on the object which can fail if some internal OkToDelete property isn't set.  If you adhere to always deleting the object by calling its Close event, you can implement whatever failure service you want when you detect an attempt to delete that is not allowed.

You can optionally override the delete function on the object (which is how many frameworks detect memory leaks, BTW) and check an internal OkToDelete property on the object.  If it is not set, you can log then crash hard with an Assert (which you'll need to do as you have no place to return error codes to).  On Win32 systems, you can use an int 3 to raise a debug exception when you want the delete to fail, which is also kinda slick as it gives you an automatic breakpoint at that position if you're debugging the application.

The private/protected destructor route only works if you have another function to call the delete and no inheritance.

Smart pointers solve the reference counting problem but not so much the OkToDelete problem.  They work for the vast majority of "not ok to delete" circumstances, but not all of them and are probably what you want.

Hope this helps.
James Birchall Send private email
Thursday, September 07, 2006
 
 
There's alwasys a way to delete something in C++. At worst, cast the pointer to char * and rummage around in the memory until you find the underlying pointer, and delete that.

That's rather pathological, but it says something about trying to enforce such things in C++. You're better off documenting your conventions instead.

One suggestion I saw once was to use different pointer types for when you pass ownership. For example, if you pass a parameter of type auto_ptr<T> then it's completely explicit that you've just passed ownership of that pointer, as the auto_ptr will delete it automatically when it goes out of scope. If, on the other hand, you pass a raw pointer, you don't really say anything about who owns what. It might be useful to establish a coding convention here of auto_ptr when transferring ownership, raw pointer when not.
Chris Tavares Send private email
Friday, September 08, 2006
 
 
> You're better off documenting your conventions instead.

A documented convention is like having no convention at all. Don't even bother. Even the smallest hurdle in deletion makes something real because it has observable consequences at compile time.
son of parnas
Saturday, September 09, 2006
 
 
You could try passing the object as a reference instead.

Someone could still recast it and delete it, but if he wants to work that hard to do something folish, let him suffer the consequences.
Wayne M.
Monday, September 11, 2006
 
 
Funnily enough, I just made an interesting solution.

I have my own allocator (for other reasons).  But I found I was copying large chunks around occasionally.  So as well as an alloc and a free, I added a inc_ref_count function, and I put a count into the top bits of my len preamble to the block.

This wasn't things with destructors or anything though, it was for const strings.
Architecture Astronaut
Wednesday, September 13, 2006
 
 

This topic is archived. No further replies will be accepted.

Other recent topics Other recent topics
 
Powered by FogBugz