Set a pointer to null when deleting?

[Joe Van Dyk]

When you delete a pointer, you should set it to NULL, right?

Joe

[Noah Roberts]

Joe Van Dyk wrote:

Object B gets deleted. It is (and out of my control) deleting the
Object A pointer. It's not setting the Object A pointer to NULL.

It probably can't. Unless the function taking the pointer requires a
pointer to pointer or a reference to a pointer then it can only set its
own copy of the pointer to 0. Pointers are just values that contain
number representing addresses in memory. If you pass a pointer by
value you can't exactly effect anything by setting that value to 0 on
the other side...the original copy of the pointer is unchanged.

So, whether or not Object B is setting the pointer to 0 is an unknown
at this time and it doesn't really matter. You need to keep in mind
that B is apparently taking ownership of the pointer it is passed and
act accordingly, by possibly copying the object and passing the copy or
some other solution that makes sense to your problem.

[Phlip]

Joe Van Dyk wrote:

I'mÂ*notÂ*terri blyÂ*smart,Â*yo uÂ*see.

Why aren't you using a smart pointer? Then they can do the thinking for you.
(Roughly..;)

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[andrew queisser]

"Joe Van Dyk" <jo********@boe ing.com> wrote in message
news:Ix******** @news.boeing.co m...

When you delete a pointer, you should set it to NULL, right?

Joe

I'm a little surprised at the responses you've been getting from some very
experienced programmers. While a smart pointer might be the best solution
for your particular problem it doesn't answer your question.

I think the correct answer to your question should be: if you intend to
check the value of the pointer later on you should set it to NULL, otherwise
it doesn't matter. Some programs use the actual value of a pointer as a flag
whether it is pointing to something that needs to be deallocated. In those
cases you should null it when deleting. However, nothing in standard C++
depends on the value of a pointer after calling delete on it.

Also keep in mind that calling delete on a null value is a noop so you don't
need code like this:

if (ptr != 0)
delete ptr; // null-check not needed
Which allows you to write code like this (no endorsements made):

Foo *foo = 0;

:
:

if (allocFoo)
foo = new Foo;

:
:

if (deleteFoo)
{
delete foo;
foo = 0;
}

:
:

delete foo;
The code above is not that likely to occur as shown but inside
constructor/destructor code you might encounter this sequence of events.

Andrew

[Joe Van Dyk]

Victor Bazarov wrote:

Joe Van Dyk wrote:

[..]
Let's see if I can explain what's going on...

I've got an object (Object A) that contains two pointers to objects
that Object A didn't create.

So something like

class Other;
class A {
Other *not_mine_1, *not_mine_2;
public:
~A() {} // do nothing to pointers
};

There's another object in the system, Object B. Object B has a
function that requires an Object A pointer.

class B {
public:
void foo(A* aptr);

private:
A* aptr_; };

Object B gets deleted. It is (and out of my control) deleting the
Object A pointer.

Which A pointer? You didn't say that B _owned_ a dynamic A object.

void B::foo(A* aptr)
{
aptr_ = aptr;
}

B::~B()
{
delete aptr_;
}

It's not setting the Object A pointer to NULL.

Shouldn't be a problem _even_if_ the B actually owned that A and had
a pointer to that dynamic object.

Now, there's threads involved here, so that may be complicating
things... but I was curious as to if the Object A pointer should be
set to NULL when Object B deletes it.

Well, no. Your problem is most likely is elsewhere. Read about "The
Rule of Three" and follow it (concerning the B class). Also, make sure
you're not deleting that B object _twice_ somewhere.

V

Yes, it's entirely possible the problem is elsewhere. I was just
wondering if it was something silly I was doing.

Joe

[Joe Van Dyk]

Phlip wrote:

Joe Van Dyk wrote:

I'm not terribly smart, you see.

Why aren't you using a smart pointer? Then they can do the thinking for you.
(Roughly..;)

Because I need to pass a raw Object A pointer to Object's B function. I
(as of now) can't change the code of class B to use smart pointers. I
don't think a smart pointer can help me there...

[Phlip]

andrew queisser wrote:

I'm a little surprised at the responses you've been getting from some very
experienced programmers.
Some of us know the textbook answer (set the friggin' pointer to NULL),
while some of us can't remember the last time we actually did that. There's
more reasons than smart pointers.

Another alternative is to set the pointer equal to the address of a static
NullObject. Consider this code:

p = getPointerFromW hatever();
if (p)
p->method(42);

Using NullObjects, that becomes this:

p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.

Replacing conditional statements with the interactions of virtual methods is
what OO is all about.
I think the correct answer to your question should be: if you intend to
check the value of the pointer later on you should set it to NULL

Even if you don't intend to, if that pointer has remaining scope, set it to
NULL to make sure (on common implementations ) you get a clean crash and not
memory corruption if you then accidentally try to dereference the pointer.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:

Another alternative is to set the pointer equal to the address of a static
NullObject. Consider this code:

p = getPointerFromW hatever();
if (p)
p->method(42);

Using NullObjects, that becomes this:

p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.

Really? What is that assert doing there then?

What type does this static NullObject have?

[Phlip]

Noah Roberts wrote:

p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.
Really? What is that assert doing there then?

It is not increasing the mental burden of reading the function. And we could
migrate it inside a new function, getReferenceFro mWhatever(), and this
function would be even shorter.
What type does this static NullObject have?

A type derived from Whatever class type that p points to, with
Whatever::metho d(int) overriden as a no-op.

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!

[Noah Roberts]

Phlip wrote:

Noah Roberts wrote:

p = getPointerFromW hatever();
assert(p);
p->method(42);

The code is one tick simpler; it has one less 'if' statement.
Really? What is that assert doing there then?

It is not increasing the mental burden of reading the function. And we could
migrate it inside a new function, getReferenceFro mWhatever(), and this
function would be even shorter.

That statement just makes no sense. I can't parse it and it doesn't
seem to apply to the question at all.

What type does this static NullObject have?

A type derived from Whatever class type that p points to, with
Whatever::metho d(int) overriden as a no-op.

That requires three things:

1) a special "NullObject " class for each and every class that could
have a pointer to it.
2) a special "NullObject " static for each of the above implementations .
3) that all classes and all member functions are polymorphic!!

Consider also functions that return values...they cannot be noops!

Now #2 is only by consequence of your initial requirements... it isn't
actually required to be static but could simply be constructed. This
results in more small objects than a static though.

#3 is the real killer.

I don't think you have thought this through quite enough yet though.

Null *pointer* object is viable. Dereference would throw an exception
or pop an assert. This of course requires the use of some form of
smart pointer...which has already been suggested.

I don't see a good implementation brewing out of your NullObject
though.

[Phlip]

Noah Roberts wrote:

>> p = getPointerFromW hatever();
>> assert(p);
>> p->method(42);
>>
>> The code is one tick simpler; it has one less 'if' statement.
>
> Really? What is that assert doing there then?
The function is less complex. It formerly had a visible controlled
statement.
> What type does this static NullObject have?
A type derived from Whatever class type that p points to, with
Whatever::metho d(int) overriden as a no-op.

That requires three things:

1) a special "NullObject " class for each and every class that could
have a pointer to it.
2) a special "NullObject " static for each of the above implementations .
3) that all classes and all member functions are polymorphic!!

Consider also functions that return values...they cannot be noops!

It also requires me to say, "Noah, I want you to find every pointer in your
program, and accomodate its pointee to have a potential NullObject _with_ a
no-op for every method."

Don't tempt me to. Instead, I will say this:

http://www.industriallogic.com/xp/re...ullObject.html

Now notice that is a _refactor_. It's not a Design Pattern, or even a
universally perfect goal. It's a path of improvement, away from redundant
'if' statements to check pointers.

The ideal situation has no 'if' statements, no pointers, and no need for
NullObjects.
Now #2 is only by consequence of your initial requirements... it isn't
actually required to be static but could simply be constructed. This
results in more small objects than a static though.
Yes, of course its storage class could be different than static. If the
pointer were smart, maybe another 'new' would work.

Because my NullObjects have no state, they can be static.
#3 is the real killer.
You made 3 up.
I don't think you have thought this through quite enough yet though.

Noope. I have indeed not thought thru all the things you will make up. ;-)

--
Phlip
http://www.greencheese.org/ZeekLand <-- NOT a blog!!!