how to check if a pointer is unbound?

[Jess]

Hello,

I tried a program as follows:

include<iostrea m>

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

[Jess]

On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:

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 <w...@hotmail.c omwrote:

On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:

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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Ron Natalie]

Howard wrote:

"Fred Kleinschmidt" <fr************ ******@boeing.c omwrote in message
news:JI******** @news.boeing.co m...

>"Ron Natalie" <ro*@spamcop.ne twrote in message
news:46******* *************** @news.newshosti ng.com...

>>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 <james.ka...@gm ail.comwrote:

On May 18, 8:27 am, Jess <w...@hotmail.c omwrote:

On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:

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 <w...@hotmail.c omwrote:

On May 18, 5:57 pm, James Kanze <james.ka...@gm ail.comwrote:

On May 18, 8:27 am, Jess <w...@hotmail.c omwrote:

On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:
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 objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Jess]

On May 19, 12:04 am, James Kanze <james.ka...@gm ail.comwrote:

On May 18, 2:22 pm, Jess <w...@hotmail.c omwrote:

On May 18, 5:57 pm, James Kanze <james.ka...@gm ail.comwrote:

On May 18, 8:27 am, Jess <w...@hotmail.c omwrote:
On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:
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 <w...@hotmail.c omwrote:

On May 19, 12:04 am, James Kanze <james.ka...@gm ail.comwrote:

On May 18, 2:22 pm, Jess <w...@hotmail.c omwrote:

On May 18, 5:57 pm, James Kanze <james.ka...@gm ail.comwrote:
On May 18, 8:27 am, Jess <w...@hotmail.c omwrote:
On May 18, 1:47 am, "Howard" <alic...@hotmai l.comwrote:
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*********@gma il.com
Conseils en informatique orientée objet/
Beratung in objektorientier ter Datenverarbeitu ng
9 place Sémard, 78210 St.-Cyr-l'École, France, [phone]

[Howard]

"Ron Natalie" <ro*@spamcop.ne twrote in message
news:46******** *************** @news.newshosti ng.com...

Howard wrote:

>"Fred Kleinschmidt" <fr************ ******@boeing.c omwrote in message
news:JI******* *@news.boeing.c om...

>>"Ron Natalie" <ro*@spamcop.ne twrote in message
news:46****** *************** *@news.newshost ing.com...
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.goo glegroups.com.. .

Hello,

I tried a program as follows:

include<iostrea m>

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?