Set a pointer to null when deleting?

[Phlip]

Re: Set a pointer to null when deleting?

andrew queisser wrote:
[color=blue]
> I'm a little surprised at the responses you've been getting from some very
> experienced programmers.[/color]

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.
[color=blue]
> 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[/color]

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]

Re: Set a pointer to null when deleting?


Phlip wrote:
[color=blue]
> 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.[/color]

Really? What is that assert doing there then?

What type does this static NullObject have?

[Phlip]

Re: Set a pointer to null when deleting?

Noah Roberts wrote:
[color=blue][color=green]
>> p = getPointerFromW hatever();
>> assert(p);
>> p->method(42);
>>
>> The code is one tick simpler; it has one less 'if' statement.[/color]
>
> Really? What is that assert doing there then?[/color]

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.
[color=blue]
> What type does this static NullObject have?[/color]

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]

Re: Set a pointer to null when deleting?


Phlip wrote:[color=blue]
> Noah Roberts wrote:
>[color=green][color=darkred]
> >> p = getPointerFromW hatever();
> >> assert(p);
> >> p->method(42);
> >>
> >> The code is one tick simpler; it has one less 'if' statement.[/color]
> >
> > Really? What is that assert doing there then?[/color]
>
> 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.[/color]

That statement just makes no sense. I can't parse it and it doesn't
seem to apply to the question at all.
[color=blue]
>[color=green]
> > What type does this static NullObject have?[/color]
>
> A type derived from Whatever class type that p points to, with
> Whatever::metho d(int) overriden as a no-op.[/color]

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]

Re: Set a pointer to null when deleting?

Noah Roberts wrote:
[color=blue][color=green][color=darkred]
>> >> 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?[/color][/color][/color]

The function is less complex. It formerly had a visible controlled
statement.
[color=blue][color=green][color=darkred]
>> > What type does this static NullObject have?[/color]
>>
>> A type derived from Whatever class type that p points to, with
>> Whatever::metho d(int) overriden as a no-op.[/color]
>
> 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![/color]

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/refactoring/nullObject.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.
[color=blue]
> 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.[/color]

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.
[color=blue]
> #3 is the real killer.[/color]

You made 3 up.
[color=blue]
> I don't think you have thought this through quite enough yet though.[/color]

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

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

[andrew queisser]

Re: Set a pointer to null when deleting?


"Noah Roberts" <roberts.noah@g mail.com> wrote in message
news:1144693750 .018400.104740@ z34g2000cwc.goo glegroups.com.. .[color=blue]
>[/color]

[snip discussion about NullObject]
[color=blue]
> 3) that all classes and all member functions are polymorphic!![/color]

Not all, only the functions that need to be instrumented. Clearly
non-polymorphic functions cannot be rerouted to a NullObject but the rest of
the class is unaffected.


I think the discussion is really more about instrumentation strategies. The
OP indicated that he doesn't have control over all the code so it seems
futile to suggest reworking the class hierarchy.


Andrew

[Noah Roberts]

Re: Set a pointer to null when deleting?


Phlip wrote:[color=blue]
> Noah Roberts wrote:[color=green]
> > 3) that all classes and all member functions are polymorphic!![/color][/color]
[color=blue][color=green]
> > #3 is the real killer.[/color]
>
> You made 3 up.[/color]

Really? Tell me then, what does the following code do?

class T
{
int * x;
public:
T() : x(0) {}
T(int v) : x(new int(x)) {}
void op() {*x = 0;}
};

class TNull : public T
{
public:
void op() {}
};

T * whatever() { return new TNull(); }

int main()
{
T * t = whatever();

t->op();

return 0;
}

If I just made #3 up then that code works, right? No undefined
behavior? Look again...you sure that your method of implementing null
object doesn't require polymorphic classes?

Look also at the problem implementing NullObject as a subclass of your
concrete object. What business does TNull have with an x? Does it
need it? Should it be there? Is TNull a T?

Simple piss poor setup yes, but it illustrates some of the problems.
What if op() did more than access a pointer? Since TNull is supposed
to represent an invalid T then how could anything performed by op() be
valid?

Refactoring works...at least in my experience. But you need to keep
certain details in mind. For instance that nullObject as shown in that
design *requires* polymorphic objects. Refactoring, like anything, can
be taken too far and you need to think about how the designs apply to
the language you are using to establish when, and when not, to use them.

[andrew queisser]

Re: Set a pointer to null when deleting?

>> I've got an object (Object A) that contains two pointers to objects that[color=blue][color=green]
>> Object A didn't create.
>>
>> There's another object in the system, Object B. Object B has a function
>> that requires an Object A pointer.
>>
>> 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.
>>
>> 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.
>>
>> <snip>
>>
>> Joe[/color]
>
> Oh, and looking at the backtrace on the segfault, it's occuring right as
> Object B deletes the pointer to Object A.
>
> And right before I call that Object B function, I'm creating a new Object
> A instance and sending a pointer to that object to Object B, if that makes
> a difference.
>
> I hope I explained that ok. I'm getting confused just thinking about it.
> I'm not terribly smart, you see.
>[/color]

Can your log the addresses of the A-objects in question after new-ing and
before deleting. Sounds like you're deleting something twice.

Andrew

[Noah Roberts]

Re: Set a pointer to null when deleting?


andrew queisser wrote:[color=blue]
> "Noah Roberts" <roberts.noah@g mail.com> wrote in message
> news:1144693750 .018400.104740@ z34g2000cwc.goo glegroups.com.. .[color=green]
> >[/color]
>
> [snip discussion about NullObject]
>[color=green]
> > 3) that all classes and all member functions are polymorphic!![/color]
>
> Not all, only the functions that need to be instrumented. Clearly
> non-polymorphic functions cannot be rerouted to a NullObject but the rest of
> the class is unaffected.[/color]

True, but you loose much of the benefit of a null object that way.
Clients would necessarily need to know which functions are ok to call
without checking and which are not. The class would need a function to
query whether it is valid or null so that clients can make the decision
before calling a function that is not polymorphic. This is a lot worse
than not having a null object in the first place because now you have a
mixture of methodologies.. ..not good.
[color=blue]
> I think the discussion is really more about instrumentation strategies. The
> OP indicated that he doesn't have control over all the code so it seems
> futile to suggest reworking the class hierarchy.[/color]

Clearly.

[Phlip]

Re: Set a pointer to null when deleting?

Noah Roberts wrote:
[color=blue][color=green][color=darkred]
>> > 3) that all classes and all member functions are polymorphic!![/color][/color][/color]
[color=blue]
> Really? Tell me then, what does the following code do?[/color]

You didn't make "all member functions polymorphic".

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

[Noah Roberts]

Re: Set a pointer to null when deleting?


Phlip wrote:
[color=blue]
> 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.[/color]

I should also point out that NullObject *is* a design pattern;
"Introduce NullObject" is a refactor.

[Phlip]

Re: Set a pointer to null when deleting?

Noah Roberts wrote:
[color=blue]
>
> Phlip wrote:
>[color=green]
>> 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.[/color]
>
> I should also point out that NullObject *is* a design pattern;
> "Introduce NullObject" is a refactor.[/color]

NullObject is an object design. It may indeed be the target of a refactor,
and it might be cited in a book on "Refactorin g to Patterns".

However, its design quality is not high enough to rank as a titular Design
Pattern, such as in a pattern book. (Before you go searching the dozens of
PLOP books for it, that would be an "argument by authority" that misses my
point.)

If you were to invent a complete object model from scratch, it should
minimize pointers, minimize 'if' checks on pointers, and not use
NullObject.
[color=blue]
> Clients would necessarily need to know which functions are ok to call
> without checking and which are not.[/color]

Right - that is indeed one of its flaws. The GOF /Design Patterns/ don't
have that problem.

And if you indeed need a NullObject, that flaw is reduced if all your
classes are very small...

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

[Noah Roberts]

Re: Set a pointer to null when deleting?


Phlip wrote:[color=blue]
> Noah Roberts wrote:
>[color=green][color=darkred]
> >> > 3) that all classes and all member functions are polymorphic!![/color][/color]
>[color=green]
> > Really? Tell me then, what does the following code do?[/color]
>
> You didn't make "all member functions polymorphic".[/color]

Umm...yes, I know. That was the whole point of my illustration. You
said I made #3 up...I just showed why your design doesn't work unless
all members are polymorphic. Are you lost?

[Phlip]

Re: Set a pointer to null when deleting?

Noah Roberts wrote:
[color=blue]
> Umm...yes, I know. That was the whole point of my illustration. You
> said I made #3 up...I just showed why your design doesn't work unless
> all members are polymorphic. Are you lost?[/color]

Were you going to make operator= virtual?

Nobody said to make all members virtual, and your other posts have
repeatedly harped on that point. I have conceded, again and again, that
NullObject is not a "Good Thing" (while you seem to think it's as good as a
Design Pattern). So, no, I don't think I'm the one who is lost here. How
about you back off, take a deep breath, and learn some more about C++
alternatives to nulling pointers.

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

[Noah Roberts]

Re: Set a pointer to null when deleting?


Phlip wrote:[color=blue]
> Noah Roberts wrote:
>[color=green]
> >
> > Phlip wrote:
> >[color=darkred]
> >> 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.[/color]
> >
> > I should also point out that NullObject *is* a design pattern;
> > "Introduce NullObject" is a refactor.[/color]
>
> NullObject is an object design. It may indeed be the target of a refactor,
> and it might be cited in a book on "Refactorin g to Patterns".
>
> However, its design quality is not high enough to rank as a titular Design
> Pattern, such as in a pattern book. (Before you go searching the dozens of
> PLOP books for it, that would be an "argument by authority" that misses my
> point.)[/color]

If you want to go that route you'll have to quantify how to call
something a pattern vs. not quite a pattern. The GOF book has several
very basic design patterns in it that are no more complex than the null
object. Just because it is not in GOF doesn't mean it is not a
pattern.
[color=blue]
>
> If you were to invent a complete object model from scratch, it should
> minimize pointers, minimize 'if' checks on pointers, and not use
> NullObject.
>[color=green]
> > Clients would necessarily need to know which functions are ok to call
> > without checking and which are not.[/color]
>
> Right - that is indeed one of its flaws. The GOF /Design Patterns/ don't
> have that problem.[/color]

Ummm...some of the GOF patterns also require polymorphism as part of
the design and fail otherwise. In fact I would go as far as saying
most are that way.
[color=blue]
>
> And if you indeed need a NullObject, that flaw is reduced if all your
> classes are very small...[/color]

You'll notice that in the link you provided the design does not specify
the complete object higherarchy. It is very likely that
MouseEventHandl er is an abstract class having at least two concrete
classes - one being the null object. Small classes is not a
requirement of the design.

You are on your way but there seems to be several areas where you lack
a complete understanding. Same can be said of everyone of course.