how to check if a pointer is unbound?

[Jess]

Hello,

I tried a program as follows:

include<iostream>

using namespace std;

class A{
public:
int x;
A():x(10){}
};

int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}

Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

Thanks,
Jess

[Zeppe]

Jess wrote:

Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

You can't, in a standard way. But you can use safer approached as
smart-pointers.

Regards,

Zeppe

[Ron Natalie]

Jess wrote:

>
Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

No. It is up to the programmer to manage pointers. Any access
to pointer value previously passed to delete is undefined. Anything
can happen from segmentation fault to apparently working normally.

Delete takes an rvalue, it can not change it's operanrd.

There's no way to test whether a pointer is bound.

If you wish to keep the pointer around and need to flag that
it has been deleted, the common way is to set the variable to
the null pointer (0).

[Fred Kleinschmidt]

"Ron Natalie" <ro*@spamcop.netwrote in message
news:46**********************@news.newshosting.com ...

Jess wrote:

>>
Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

No. It is up to the programmer to manage pointers. Any access
to pointer value previously passed to delete is undefined. Anything
can happen from segmentation fault to apparently working normally.

Delete takes an rvalue, it can not change it's operanrd.

There's no way to test whether a pointer is bound.

If you wish to keep the pointer around and need to flag that
it has been deleted, the common way is to set the variable to
the null pointer (0).

That will not work. You removed the relevant part of the OP's post:
int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}
So, what happens if he adds
p=NULL;
after deleting p?

He still has the same problem, since he is trying to use /q/, not /p/
And it it is not reasonable for you to say that he should set q=NULL
too. These may occur in different modules, and when he deletes p,
there is no way for that module to know whether other pointers have
been set to point to the same place as p.
--
Fred L. Kleinschmidt
Boeing Associate Technical Fellow
Aero Stability and Controls Computing

[Howard]

"Fred Kleinschmidt" <fr******************@boeing.comwrote in message
news:JI********@news.boeing.com...

>
"Ron Natalie" <ro*@spamcop.netwrote in message
news:46**********************@news.newshosting.com ...

>Jess wrote:

>>>
Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

No. It is up to the programmer to manage pointers. Any access
to pointer value previously passed to delete is undefined. Anything
can happen from segmentation fault to apparently working normally.

Delete takes an rvalue, it can not change it's operanrd.

There's no way to test whether a pointer is bound.

If you wish to keep the pointer around and need to flag that
it has been deleted, the common way is to set the variable to
the null pointer (0).

That will not work. You removed the relevant part of the OP's post:
int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}
So, what happens if he adds
p=NULL;
after deleting p?

He still has the same problem, since he is trying to use /q/, not /p/
And it it is not reasonable for you to say that he should set q=NULL
too. These may occur in different modules, and when he deletes p,
there is no way for that module to know whether other pointers have
been set to point to the same place as p.
--

I don't see anywhere that Victor said setting p to NULL would solve the
problem in that specific example. He just said that the common way to know
that a pointer has been passed to delete was to set it to NULL (after
calling delete). That's true.

In the specific example, he could also set q=NULL. (And then check it
before calling cout.)

If one wants to address a more complex case than that silly example, then
the answer is still the same, really. It's up to the program[mer] to keep
track of whether any pointer has been deleted or not. And one way to do
that is to set it to NULL.

If you're setting multiple pointers to point to a given object, then
*somewhere* you need to keep that information stored. That may be in a
reference-counted pointer, but it may not. After all, you may *want* the
object completely destroyed when passing any one of the pointers to it to
delete, (whereas a reference-counted solution would keep it alive until the
last pointer to it was passed to delete).

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.

In any case, someone needs to *explicitly* keep track of the validity of the
pointer, because it can't do the job for you.

-Howard

[Richard Herring]

In message <EO****************@bgtnsc04-news.ops.worldnet.att.net>,
Howard <al*****@hotmail.comwrites

>
"Fred Kleinschmidt" <fr******************@boeing.comwrote in message
news:JI********@news.boeing.com...

>>
"Ron Natalie" <ro*@spamcop.netwrote in message
news:46**********************@news.newshosting.co m...

>>Jess wrote:
Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

No. It is up to the programmer to manage pointers. Any access
to pointer value previously passed to delete is undefined. Anything
can happen from segmentation fault to apparently working normally.

Delete takes an rvalue, it can not change it's operanrd.

There's no way to test whether a pointer is bound.

If you wish to keep the pointer around and need to flag that
it has been deleted, the common way is to set the variable to
the null pointer (0).

That will not work. You removed the relevant part of the OP's post:
int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}
So, what happens if he adds
p=NULL;
after deleting p?

Nobody seems to have pointed out that he's already in terminal trouble,
since what p pointed to wasn't created by new in the first place :-(

>>
He still has the same problem, since he is trying to use /q/, not /p/
And it it is not reasonable for you to say that he should set q=NULL
too. These may occur in different modules, and when he deletes p,
there is no way for that module to know whether other pointers have
been set to point to the same place as p.

I don't see anywhere that Victor said setting p to NULL would solve the
problem in that specific example. He just said that the common way to know
that a pointer has been passed to delete was to set it to NULL (after
calling delete). That's true.

In the specific example, he could also set q=NULL. (And then check it
before calling cout.)

If one wants to address a more complex case than that silly example, then
the answer is still the same, really. It's up to the program[mer] to keep
track of whether any pointer has been deleted or not. And one way to do
that is to set it to NULL.

If you're setting multiple pointers to point to a given object, then
*somewhere* you need to keep that information stored. That may be in a
reference-counted pointer, but it may not. After all, you may *want* the
object completely destroyed when passing any one of the pointers to it to
delete, (whereas a reference-counted solution would keep it alive until the
last pointer to it was passed to delete).

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.

In any case, someone needs to *explicitly* keep track of the validity of the
pointer, because it can't do the job for you.

-Howard

--
Richard Herring

[Howard]

"Richard Herring" <ju**@[127.0.0.1]wrote in message
news:hN**************@baesystems.com...

>>So, what happens if he adds
p=NULL;
after deleting p?

Nobody seems to have pointed out that he's already in terminal trouble,
since what p pointed to wasn't created by new in the first place :-(

D'oh! :-)

[red floyd]

Jess wrote:

Hello,

I tried a program as follows:

include<iostream>

using namespace std;

class A{
public:
int x;
A():x(10){}
};

int main(){
A a;
A* p = &a;
A* q = p;
delete p;

At this point anything can happen. "delete p" causes Undefined
Behavior, as p was *NOT* allocated on the free store. Any questions
about what happens next has no valid answer, other than "anything can
happen".

cout << q << endl;
return 0;
}

Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

See above.

[red floyd]

Richard Herring wrote:

>

Nobody seems to have pointed out that he's already in terminal trouble,
since what p pointed to wasn't created by new in the first place :-(

I caught it :-), but I hadn't read the rest of this thread yet.

[Jess]

On May 18, 2:09 am, Richard Herring <ju**@[127.0.0.1]wrote:

In message <EO_2i.1201$[e-mail]>,
Howard <[e-mail]

"Fred Kleinschmidt" <[e-mail] in message
news:JI********@news.boeing.com...

"Ron Natalie" <[e-mail] in message
news:46**********************@news.newshosting.co m...
Jess wrote:

>>Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

>No. It is up to the programmer to manage pointers. Any access
to pointer value previously passed to delete is undefined. Anything
can happen from segmentation fault to apparently working normally.

>Delete takes an rvalue, it can not change it's operanrd.

>There's no way to test whether a pointer is bound.

>If you wish to keep the pointer around and need to flag that
it has been deleted, the common way is to set the variable to
the null pointer (0).

That will not work. You removed the relevant part of the OP's post:
int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}

So, what happens if he adds
p=NULL;
after deleting p?

Nobody seems to have pointed out that he's already in terminal trouble,
since what p pointed to wasn't created by new in the first place :-(

He still has the same problem, since he is trying to use /q/, not /p/
And it it is not reasonable for you to say that he should set q=NULL
too. These may occur in different modules, and when he deletes p,
there is no way for that module to know whether other pointers have
been set to point to the same place as p.

I don't see anywhere that Victor said setting p to NULL would solve the
problem in that specific example. He just said that the common way to know
that a pointer has been passed to delete was to set it to NULL (after
calling delete). That's true.

In the specific example, he could also set q=NULL. (And then check it
before calling cout.)

If one wants to address a more complex case than that silly example, then
the answer is still the same, really. It's up to the program[mer] to keep
track of whether any pointer has been deleted or not. And one way to do
that is to set it to NULL.

If you're setting multiple pointers to point to a given object, then
*somewhere* you need to keep that information stored. That may be in a
reference-counted pointer, but it may not. After all, you may *want* the
object completely destroyed when passing any one of the pointers to it to
delete, (whereas a reference-counted solution would keep it alive until the
last pointer to it was passed to delete).

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.

In any case, someone needs to *explicitly* keep track of the validity of the
pointer, because it can't do the job for you.

-Howard

--
Richard Herring

Right, I forgot I can't delete statically allocated object! :)

[Jess]

On May 18, 1:47 am, "Howard" <[e-mail]:

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.

I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?

Thanks,
Jess

[James Kanze]

On May 18, 8:27 am, Jess <[e-mail]:

On May 18, 1:47 am, "Howard" <[e-mail]:

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers ithas
assigned values to, and assigns NULL to them.

I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?

It's called the Observer pattern. A simple version of it is
used boost::weak_ptr, and an even simpler version in my
ManagedPtr. More generally, however, any object "interested" in
your object registers as an observer, and you inform all
interested objects in the destructor that you're no longer
available. The interested objects then take whatever steps they
deem appropriate: it can be as simple as nulling a pointer, but
will more often (in my experience) involve removing the pointer
from a set or a map, or even obtaining alternative resources or
changing it's own internal state.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ron Natalie]

Howard wrote:

"Fred Kleinschmidt" <fr******************@boeing.comwrote in message
news:JI********@news.boeing.com...

>"Ron Natalie" <ro*@spamcop.netwrote in message
news:46**********************@news.newshosting.co m...

>>Jess wrote:

I don't see anywhere that Victor said setting p to NULL would solve the
problem in that specific example.

Don't call me Victor (even if we are more or less interchangable).

[Jess]

On May 18, 5:57 pm, James Kanze <[e-mail]:

On May 18, 8:27 am, Jess <[e-mail]:

On May 18, 1:47 am, "Howard" <[e-mail]:

One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.

I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?

It's called the Observer pattern. A simple version of it is
used boost::weak_ptr, and an even simpler version in my
ManagedPtr. More generally, however, any object "interested" in
your object registers as an observer, and you inform all
interested objects in the destructor that you're no longer
available.

So an "interested" object (call it A) should have a field to indicate
whether the object it's interested in (call it B) is still available
and this field can be set (possibly via some function of A)?

The interested objects then take whatever steps they
deem appropriate:

Should the interested object (A) take this action as soon as it sees
the object (B) is destroyed, or, at some other time (e.g. when A is
about to use B)?

it can be as simple as nulling a pointer, but
will more often (in my experience) involve removing the pointer
from a set or a map,

Does this set or map store all the pointers it has that point to the
external objects (including B here)?

Many thanks,
Jess

[James Kanze]

On May 18, 2:22 pm, Jess <[e-mail]:

On May 18, 5:57 pm, James Kanze <[e-mail]:

On May 18, 8:27 am, Jess <[e-mail]:

On May 18, 1:47 am, "Howard" <[e-mail]:
One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps trackof which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.
I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?

It's called the Observer pattern. A simple version of it is
used boost::weak_ptr, and an even simpler version in my
ManagedPtr. More generally, however, any object "interested" in
your object registers as an observer, and you inform all
interested objects in the destructor that you're no longer
available.

So an "interested" object (call it A) should have a field to indicate
whether the object it's interested in (call it B) is still available
and this field can be set (possibly via some function of A)?

Maybe. One of the most frequent uses of pointers is navigation.
If there is a one to n relationship, the object on the one side
will typically have a container with the pointers. The call
back for "object deleted" just removes the pointer from the
container: no flags, no extra pointers, no nothing.

The interested objects then take whatever steps they
deem appropriate:

Should the interested object (A) take this action as soon as it sees
the object (B) is destroyed, or, at some other time (e.g. when A is
about to use B)?

Normally, as soon as it is notified of the destruction.
Otherwise, it has to set a flag of some sort, and test it later.

it can be as simple as nulling a pointer, but
will more often (in my experience) involve removing the pointer
from a set or a map,

Does this set or map store all the pointers it has that point to the
external objects (including B here)?

Maybe. It depends on the design. An object doesn't contain a
pointer to another object just for the fun of having pointers to
manage. It contains the pointer for a specific purpose,
according to the design of the application. What it should do
if the object in question is destructed depends on the design,
the role of the two objects in that design, and the relationship
between the objects. It's very application specific.

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jess]

On May 19, 12:04 am, James Kanze <[e-mail]:

On May 18, 2:22 pm, Jess <[e-mail]:

On May 18, 5:57 pm, James Kanze <[e-mail]:

On May 18, 8:27 am, Jess <[e-mail]:
On May 18, 1:47 am, "Howard" <[e-mail]:
One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.
I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?
It's called the Observer pattern. A simple version of it is
used boost::weak_ptr, and an even simpler version in my
ManagedPtr. More generally, however, any object "interested" in
your object registers as an observer, and you inform all
interested objects in the destructor that you're no longer
available.

So an "interested" object (call it A) should have a field to indicate
whether the object it's interested in (call it B) is still available
and this field can be set (possibly via some function of A)?

Maybe. One of the most frequent uses of pointers is navigation.
If there is a one to n relationship, the object on the one side
will typically have a container with the pointers. The call
back for "object deleted" just removes the pointer from the
container: no flags, no extra pointers, no nothing.

The message that the object has been deleted must be passed on to the
owner of pointer container. Do you think a possible way is to
implement member function of the owner of the container, so that this
function can be called when a object is deleted?

Thanks,
Jess

[James Kanze]

On May 19, 12:49 pm, Jess <[e-mail]:

On May 19, 12:04 am, James Kanze <[e-mail]:

On May 18, 2:22 pm, Jess <[e-mail]:

On May 18, 5:57 pm, James Kanze <[e-mail]:
On May 18, 8:27 am, Jess <[e-mail]:
On May 18, 1:47 am, "Howard" <[e-mail]:
One solution would be to create another object which owns the original
object, and which hands out values to the pointers, and keeps track of which
pointers have been given values. Then, when the owning object is deleted,
it deletes the owned object, and also loops through all the pointers it has
assigned values to, and assigns NULL to them.
I know how to keep a reference count, but can you please show me how
the owner of the object can keep track of which pointers are pointing
to the object and set all of them to NULL when the object is
destroyed?
It's called the Observer pattern. A simple version of it is
used boost::weak_ptr, and an even simpler version in my
ManagedPtr. More generally, however, any object "interested" in
your object registers as an observer, and you inform all
interested objects in the destructor that you're no longer
available.
So an "interested" object (call it A) should have a field to indicate
whether the object it's interested in (call it B) is still available
and this field can be set (possibly via some function of A)?

Maybe. One of the most frequent uses of pointers is navigation.
If there is a one to n relationship, the object on the one side
will typically have a container with the pointers. The call
back for "object deleted" just removes the pointer from the
container: no flags, no extra pointers, no nothing.

The message that the object has been deleted must be passed on to the
owner of pointer container. Do you think a possible way is to
implement member function of the owner of the container, so that this
function can be called when a object is deleted?

Of course. This is a classical example of the observer pattern.

--
James Kanze (Gabi Software) email: ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Howard]

"Ron Natalie" <ro*@spamcop.netwrote in message
news:46***********************@news.newshosting.co m...

Howard wrote:

>"Fred Kleinschmidt" <fr******************@boeing.comwrote in message
news:JI********@news.boeing.com...

>>"Ron Natalie" <ro*@spamcop.netwrote in message
news:46**********************@news.newshosting.c om...
Jess wrote:

>I don't see anywhere that Victor said setting p to NULL would solve the
problem in that specific example.

Don't call me Victor (even if we are more or less interchangable).

Oops! Sorry! :-}

-Howard (I think)

[JohnQ]

"Jess" <wd***@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

Hello,

I tried a program as follows:

include<iostream>

using namespace std;

class A{
public:
int x;
A():x(10){}
};

int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}

Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

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).

John

[Alf P. Steinbach]

* JohnQ:

>
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).

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).

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.
--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Clark Cox]

On 2007-05-22 15:07:10 -0700, "JohnQ"
<jo***********************@yahoo.comsaid:

>
"Jess" <wd***@hotmail.comwrote in message
news:11**********************@k79g2000hse.googlegr oups.com...

>Hello,

I tried a program as follows:

include<iostream>

using namespace std;

class A{
public:
int x;
A():x(10){}
};

int main(){
A a;
A* p = &a;
A* q = p;
delete p;
cout << q << endl;
return 0;
}

Since "q" should be unbound, I thought the output would be "0".
However, the result was segmentation fault. How can I check if a
pointer is unbound?

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;
}

--
Clark S. Cox III
cl*******@gmail.com

[JohnQ]

"Alf P. Steinbach" <al***@start.nowrote in message
news:5b*************@mid.individual.net...

>* JohnQ:

>>
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).

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]

On May 23, 12:16 am, "Alf P. Steinbach" <[e-mail]:

* JohnQ:

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 ptrand
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).

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.)

--
James Kanze (GABI Software) email:ja*********@gmail.com
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Roland Pibinger]

On Tue, 22 May 2007 22:07:10 GMT, "JohnQ" wrote:

>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.
--
Roland Pibinger
"The best software is simple, elegant, and full of drama" - Grady Booch

[Alf P. Steinbach]

* James Kanze:

On May 23, 12:16 am, "Alf P. Steinbach" <[e-mail]:

>* JohnQ:

>>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).

>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).

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

--
A: Because it messes up the order in which people normally read text.
Q: Why is it such a bad thing?
A: Top-posting.
Q: What is the most annoying thing on usenet and in e-mail?

[Martijn van Buul]

* JohnQ:

> 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).

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 - pi**@dohd.org

[Martijn van Buul]

* Roland Pibinger:

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

That's short. And wrong.

--
Martijn van Buul - pi**@dohd.org

[Marcus Kwok]

JohnQ <jo***********************@yahoo.comwrote:

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_f...ml#delete-zero

--
Marcus Kwok
Replace 'invalid' with 'net' to reply

[Howard]

"Marcus Kwok" <ri******@gehennom.invalidwrote in message
news:f3**********@news-int2.gatech.edu...

JohnQ <jo***********************@yahoo.comwrote:

>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_f...ml#delete-zero

God has an FAQ now? :-)

-Howard

[JohnQ]

"Martijn van Buul" <pi**@dohd.orgwrote in message
news:sl******************@mud.stack.nl...

>* JohnQ:

>> 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).

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]

"Marcus Kwok" <ri******@gehennom.invalidwrote in message
news:f3**********@news-int2.gatech.edu...

JohnQ <jo***********************@yahoo.comwrote:

>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_f...ml#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