How do you tell if a pointer doesn't point to anything...
 

....Without using NULL? There must be a way; people keep talking about
storing pointers to objects in different locations in the program.

Thanks.

Re: How do you tell if a pointer doesn't point to anything...
 

Narf the Mouse wrote:
> ...Without using NULL? There must be a way;

There isn't.

Re: How do you tell if a pointer doesn't point to anything...
 

On Nov 25, 10:50 pm, "Noah Roberts" <roberts.n...@gmail.com> wrote:
> Narf the Mouse wrote:
> > ...Without using NULL? There must be a way;
>
> There isn't.

Er...Then what do people do with all those pointers scattered around?

Re: How do you tell if a pointer doesn't point to anything...
 

"Narf the Mouse" <largemouse@gmail.com> wrote in message
news:1164523708.650762.23570@j44g2000cwa.googlegro ups.com...
> ...Without using NULL?


If your program does not initialize or assign a value
to a pointer, then it doesn't point to anything.
That's how you tell.

> There must be a way; people keep talking about
> storing pointers to objects in different locations in the program.

That doesn't really have anything to do with
your question.

-Mike

Re: How do you tell if a pointer doesn't point to anything...
 

On Nov 25, 11:15 pm, "Mike Wahler" <mkwah...@mkwahler.net> wrote:
> "Narf the Mouse" <largemo...@gmail.com> wrote in messagenews:1164523708.650762.23570@j44g2000cwa.go oglegroups.com...
>
> > ...Without using NULL?
>
> If your program does not initialize or assign a value
> to a pointer, then it doesn't point to anything.
> That's how you tell.

At which point it crashes, which isn't what I want.

> > There must be a way; people keep talking about
> > storing pointers to objects in different locations in the program.
>
> That doesn't really have anything to do with
> your question.
>
> -Mike

Can't I be an optimist on an unrelated tangent?

In other news, if I just make the pointer equal to an object of class
NullObjectClass, then include a 'bool isNull ();' function in all the
classes, I can write the program so that a relatively equivalent thing
will happen. I can even reuse the same type of NullObject for each type
of pointer.

So, if anyone wants to know how to accomplish something along those
lines, that's one way.

Re: How do you tell if a pointer doesn't point to anything...
 

Narf the Mouse wrote:

>
>
> On Nov 25, 10:50 pm, "Noah Roberts" <roberts.n...@gmail.com> wrote:
>> Narf the Mouse wrote:
>> > ...Without using NULL? There must be a way;
>>
>> There isn't.
>
> Er...Then what do people do with all those pointers scattered around?

They think through the program and prove for every single line where they
use a pointer that it is valid. That is hard (in fact, it is equivalent to
the halting problem, so you cannot leave this kind of deduction to the
compiler). It gets even harder in the presence of code that might throw
exceptions (since every new has to pair with exactly one delete along each
execution path). All of this being so difficult is one of the main reasons
that pointers are best avoided.


Best

Kai-Uwe Bux

Re: How do you tell if a pointer doesn't point to anything...
 

Narf the Mouse wrote:
>
> On Nov 25, 10:50 pm, "Noah Roberts" <roberts.n...@gmail.com> wrote:
>
>>Narf the Mouse wrote:
>>
>>>...Without using NULL? There must be a way;
>>
>>There isn't.
>
>
> Er...Then what do people do with all those pointers scattered around?
>
What pointers? If you're that concerned, either set them to NULL after
delete or avoid them altogether and use smart pointer objects.

--
Ian Collins.

Re: How do you tell if a pointer doesn't point to anything...
 

Narf the Mouse wrote:
> On Nov 25, 11:15 pm, "Mike Wahler" <mkwah...@mkwahler.net> wrote:
> > "Narf the Mouse" <largemo...@gmail.com> wrote in messagenews:1164523708.650762.23570@j44g2000cwa.go oglegroups.com...
> >
> > > ...Without using NULL?
> >
> > If your program does not initialize or assign a value
> > to a pointer, then it doesn't point to anything.
> > That's how you tell.
>
> At which point it crashes, which isn't what I want.
>
> > > There must be a way; people keep talking about
> > > storing pointers to objects in different locations in the program.
> >
> > That doesn't really have anything to do with
> > your question.
> >
> > -Mike
>
> Can't I be an optimist on an unrelated tangent?
>
> In other news, if I just make the pointer equal to an object of class
> NullObjectClass, then include a 'bool isNull ();' function in all the
> classes, I can write the program so that a relatively equivalent thing
> will happen. I can even reuse the same type of NullObject for each type
> of pointer.

You can do that but you presumably need a way to remember what type of
object it points to. You could also wrap your pointer in some class and
keep the raw pointer private, but what you end up with looks quite
similar to a smart pointer:

This one is pretty good and is destined to become part of the C++
standard:

http://www.boost.org/libs/smart_ptr/shared_ptr.htm

It manages the raw pointers life and deletes it when the last reference
is destroyed. Can also be checked for null. Also takes care of
downcasting and dynamic up casting and so on.

regards
Andy Little

Re: How do you tell if a pointer doesn't point to anything...
 

"Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
news:ekbg7j$ofb$1@murdoch.acc.Virginia.EDU...
> Narf the Mouse wrote:
>
>>
>>
>> On Nov 25, 10:50 pm, "Noah Roberts" <roberts.n...@gmail.com> wrote:
>>> Narf the Mouse wrote:
>>> > ...Without using NULL? There must be a way;
>>>
>>> There isn't.
>>
>> Er...Then what do people do with all those pointers scattered around?
>
> They think through the program and prove for every single line where they
> use a pointer that it is valid. That is hard (in fact, it is equivalent to
> the halting problem, so you cannot leave this kind of deduction to the
> compiler). It gets even harder in the presence of code that might throw
> exceptions (since every new has to pair with exactly one delete along each
> execution path). All of this being so difficult is one of the main reasons
> that pointers are best avoided.

Actually, I find it just as hard as ensuring my integer variables have valid
data. If you think about what you're doing, it's not necessarily as hard as
anything else.

Just make sure a couple of things and you'll be fine.
1. When you create a pointer, intialize it. Either to NULL to some valid
location.
2. When you change a pointer, think about what it was pointing to before, is
it now a dangling pointer (nothing pointing to it) so has to be deleted? Or
something else?
3. When you're done using a pointer either delete it or assign it to NULL.

Most of the cases I deal with pointers are for containers of polymorphic
objects. It's usually very simple in that case, I new it and push it onto
the container.

When ever I remove it from a contaer, I delete it.

When I"im doing with a container I iteratre though it and delete all the
pointers.

For this I find I hardly ever have problems with my pointers pointing to
invalid data.

Re: How do you tell if a pointer doesn't point to anything...
 

Jim Langston wrote:
> "Kai-Uwe Bux" <jkherciueh@gmx.net> wrote in message
> news:ekbg7j$ofb$1@murdoch.acc.Virginia.EDU...
>> Narf the Mouse wrote:
>>
>>>
>>> On Nov 25, 10:50 pm, "Noah Roberts" <roberts.n...@gmail.com> wrote:
>>>> Narf the Mouse wrote:
>>>>> ...Without using NULL? There must be a way;
>>>> There isn't.
>>> Er...Then what do people do with all those pointers scattered around?
>> They think through the program and prove for every single line where they
>> use a pointer that it is valid. That is hard (in fact, it is equivalent to
>> the halting problem, so you cannot leave this kind of deduction to the
>> compiler). It gets even harder in the presence of code that might throw
>> exceptions (since every new has to pair with exactly one delete along each
>> execution path). All of this being so difficult is one of the main reasons
>> that pointers are best avoided.
>
> Actually, I find it just as hard as ensuring my integer variables have valid
> data. If you think about what you're doing, it's not necessarily as hard as
> anything else.

Except that you don't have to worry about cleaning up an integer.
Everything is nice and automatic.

Of course, more robust code would probably be using the RAII paradigm.