how to check if a pointer is unbound?

[Clark Cox]

Why doesn't/can't C++ set deleted pointers (and freed memory pointers
therefor) to null? It would seem that dereferencing a null pointer and
getting an exception is preferable than dereferencing and REusing a ptr and
not noticing that it had already been freed/deleted. (I know this has been
asked and answered before, but I forgot what the short answer is).

Because it isn't possible (without a garbage collector or some similar
mechanism) to track down all of the pointers that might point to or
into the same object:


int main()
{
int *p1 = new int;
int *p2 = p1;

delete p1;
//p2 still has old value
return 0;
}

 

[JohnQ]

* JohnQ:

C++ doesn't force that inefficiency on you,

I fail to see where the 'p = 0' added to delete and free would cause
inefficiency.

but it allows you to easily define that functionality yourself if you want
it:

template< typename T >
void destroy( T*& p ) { delete p; p = 0; }

I do this in my memory manager (set the pointer to 0). (Overridden global
new and delete operators).

(plus more overloads plus destroyArray).

It isn't necessarily a good idea.

The problem is that by relying on defined behavior that defined behavior
may easily be abused, resulting in nullpointer-checks everywhere.

Is what happens when one tries to dereference a ptr that has been "nulled"
platform-specific?.

John

 

[James Kanze]

* JohnQ:

C++ doesn't force that inefficiency on you, but it allows you to easily
define that functionality yourself if you want it:

template< typename T >
void destroy( T*& p ) { delete p; p = 0; }

(plus more overloads plus destroyArray).

The answer doesn't have much to do with efficiency, at least not
here. The answer is that just setting the argument to delete to
null doesn't help much (and of course, the argument to delete
isn't even necessarily an lvalue). In order to be helpful, it
would be necessary to set *all* of the pointer to the object to
null. And this isn't reasonably possible with the language
specified as it currently is, and maintaining any degree of C
compatibility. (It might be possible with "fat" pointers, with
each pointer linked back to the originating source of the
pointer in some way.)

 

[Roland Pibinger]

Why doesn't/can't C++ set deleted pointers (and freed memory pointers
therefor) to null? It would seem that dereferencing a null pointer and
getting an exception is preferable than dereferencing and REusing a ptr and
not noticing that it had already been freed/deleted. (I know this has been
asked and answered before, but I forgot what the short answer is).

The short answer is that you should use delete only in a destructor.

 

[Alf P. Steinbach]

* James Kanze:

The answer doesn't have much to do with efficiency, at least not
here. The answer is that just setting the argument to delete to
null doesn't help much (and of course, the argument to delete
isn't even necessarily an lvalue).

Nulling a pointer after delete can in some situations help find bugs,
and it can be done automatically when the argument is a non-const
lvalue. That's why it's often done by sloppy coders (Microsoft comes to
mind). What you call "the" answer is another aspect, which is also
relevant, but the inference

In order to be helpful, it
would be necessary to set *all* of the pointer to the object to
null.

is not valid -- one shouldn't refrain from detecting and correcting
bugs just because one can't detect and correct them all (not that I
endorse the technique of nulling pointers, but the argument is invalid).

Cheers,

- Alf

 

[Martijn van Buul]

* JohnQ:

I do this in my memory manager (set the pointer to 0). (Overridden global
new and delete operators).

That is a noop, as void operator delete (void *) passes the pointer of the
to-be-released chunk by value, and not by reference. And even if it did,
it wouldn't work for objects being pointed to by multiple pointers.

 

[Martijn van Buul]

* Roland Pibinger:

The short answer is that you should use delete only in a destructor.

That's short. And wrong.

 

[Marcus Kwok]

Why doesn't/can't C++ set deleted pointers (and freed memory pointers
therefor) to null?

See The Creator's FAQ:
http://www.research.att.com/~bs/bs_faq2.html#delete-zero

 

[Howard]

See The Creator's FAQ:
http://www.research.att.com/~bs/bs_faq2.html#delete-zero

God has an FAQ now?

-Howard

 

[JohnQ]

* JohnQ:


That is a noop, as void operator delete (void *) passes the pointer of the
to-be-released chunk by value, and not by reference.

Maybe my compiler is accepting void*&?

And even if it did,
it wouldn't work for objects being pointed to by multiple pointers.

Understood. It's a caveat.

John

 

[JohnQ]

See The Creator's FAQ:
http://www.research.att.com/~bs/bs_faq2.html#delete-zero

In which he states: "C++ explicitly allows an implementation of delete to
zero out an lvalue operand, and I had hoped that implementations would do
that, but that idea doesn't seem to have become popular with implementers. "

That's probably why void*& as the argument to the delete operator works. Now
I'm wondering if I have to overload the void* version also to be sure my
operators will be called. (I won't be back into compile mode for a few more
days, else I'd test it).

John