tags:

views:

267

answers:

5

I have a previous question that was answered in which I describe difficulties catching an exception when I try to access an object that has been deallocated by a third-party function. The function sometimes does and sometimes doesn't deallocate the object.

In order to avoid having to use a try/catch block to catch the SEH Exception as described in the previous question, I need to be able to tell whether the object has been deallocated or not.

How can I determine if a C++ object has been deallocated or is still a valid pointer?

+8  A: 

You can't easily tell just by looking at the memory location if the object is still allocated or not. There might be some black magic tricks to do that, but a much cleaner way would be to build a call-back mechanism into the object's destructor.

Adrian Grigore
I don't control the object definition - it is an object returned from the third-party dll.
Michael Bray
+3  A: 

You can't. If the function you're using doesn't give you ways of knowing whether or not it deallocated the object itself, there's no way you can find out.

Edit: Well, unless the object in question is an instance of your own class and you can modify the destructor like Adrian suggested.

sepp2k
+2  A: 

I don't think you can, at least not in a standard way. There is, as far as I know, no requirement that the heap manager be able to detect if an address has been previously returned.

If there was, there would be no need to make it undefined what delete is to do with invalid pointers.

unwind
I think you could override malloc and free to achieve something like that, but that's what I would call black magic...
Adrian Grigore
+5  A: 

I think you're asking the wrong question. The question really ought to be:

Why do I feel like I need to look at some address in order to find out whether the pointer pointing there refers to an object or to the garbage left after an ex-object was deleted?

Honestly, you shouldn't be in that situation. If an object is deleted, why are you left with a pointer to its ex-address? Ideally, the pointer should be out of scope. If that isn't possible in your code, it should have been set to NULL.

sbi
I would revise your statement... I shouldn't BE PUT in that position. Unfortunately, that's the position I've been put in by the third party code. Sometimes it frees it and sometimes it doesn't.
Michael Bray
Ouch. A 3rd-party lib that sometimes hands out a pointer to an already deleted object? And you can't file a bug report? And the lib is still worth using? That sounds like a very bad situation.
sbi
A: 

If you control all the code that accesses your object, then the proper way is to use boost::shared_ptr to manage the lifetime of the object and then boost::weak_ptr for any references that you expect to remain after the object is deleted.

Looking at your other question about a third party library though, you may be stuck. If the library is prone to deleting the object as a side effect of other options, then likely you're not intended to keep those pointers around. Is there a reason that you can't re-fetch the object any time you need it, or at least after doing anything that may have deleted it?

Alan