pointer to reference conversion

[toton]

Hi,
This is continuation of topic pointer & reference doubt.
http://groups.google.com/group/comp....304d7d77f6ccca
But I think it is better to have a new topic rather than continuing on
old one.

As now I am sure pointer to reference and reference to pointer are
freely convertable, the potential danger lies in the first one. Pointer
may be NULL, but reference should not be.
My question is, what is the best way to answer it?
just assert that the pointer is not NULL, before dereferencing it?
However that will lead to a debug only checking. In the post
http://groups.google.com/group/comp....d52926a25a167c
Frederick Gotham had suggested an alternative method in some different
context, which throws an exception. Thus I think it is valid even at
non-debug mode and catches such potential problem at runtime.

Which one should be preferred? and any one deals with this conversion
problem in some standard way?
Going a little further, like the new operator is written throw a
bad_alloc, so one need not to check NULL pointer afrer a new (and one
can overload global new as well as specific new according to his
convenience to have some specific handler also) , can the dereferencing
operator be overloaded (globally and class specific way) to throw some
exception when one is dereferencing a NULL pointer?
Ofcouse the danger will not be fully eleminated (as one can have a
pointer which is not NULL, but points to some invalid object, like
dereferencing a pointer after delete. But such problem can be handled
with a safe_delete which sets the pointer to NULL. Or also in
conjugation with nullptr
http://www.open-std.org/jtc1/sc22/wg...2003/n1488.pdf ),
but it will get significantly removed.
Looking for some suggestions and expert comments.

Thanks

[Daniel T.]

"toton" <ab*******@gmail.comwrote:

As now I am sure pointer to reference and reference to pointer are
freely convertable, the potential danger lies in the first one. Pointer
may be NULL, but reference should not be.
My question is, what is the best way to answer it?
just assert that the pointer is not NULL, before dereferencing it?
However that will lead to a debug only checking. In the [another] post
Frederick Gotham had suggested an alternative method in some different
context, which throws an exception. Thus I think it is valid even at
non-debug mode and catches such potential problem at runtime.

Which one should be preferred?

Dereferencing an invalid pointer (including one that is null) is an
error perpetrated by the programmer doing the dereferencing and there
isn't much that can be done after the fact to catch the error. The best
solution is to consistently make sure the pointer is not invalid before
dereferencing it, and the only way that can be done is through static
program analysis (i.e. the programmer knows at compile time that there
is no way the pointer can be invalid.)

It is possible to write a smart pointer that can monitor the program for
this problem at run-time, but there is no way for the code to ensure
that such a smart pointer is always used for all dynamic allocations,
and never used for pointers pointing to non-dynamically allocated
memory. Also such solutions tend to be rather heavy weight and tend to
get in the way of the conscientious programmer that ensures that all
pointer dereferences are valid.

The only real solution here is for the programmer(s) to pay attention to
the fundamentals. Don't ever dereference an invalid pointer.

--
There are two things that simply cannot be doubted. Logic and our
ability to sense the world around us. Doubt those, and you no longer
have anyone to discuss it with, nor any ability to discuss it.

[Howard]

"toton" <ab*******@gmail.comwrote in message
news:11*********************@p79g2000cwp.googlegro ups.com...

Hi,
This is continuation of topic pointer & reference doubt.
http://groups.google.com/group/comp....304d7d77f6ccca
But I think it is better to have a new topic rather than continuing on
old one.

As now I am sure pointer to reference and reference to pointer are
freely convertable, the potential danger lies in the first one. Pointer
may be NULL, but reference should not be.
My question is, what is the best way to answer it?
just assert that the pointer is not NULL, before dereferencing it?

I'm not sure what you mean by "the best way to answer it", but if I
understand correctly, the best way to avoid the problem is to, well, avoid
the problem. Design your app so that there is no case where you're going to
get a NULL pointer passed to code which needs it to be non-NULL.

In cases where a NULL is normal and expected, then you shouldn't be using a
reference in the first place. Doing so is an error in design, and you
shouldn't have to code around such an error.

(This is the purpose of an assert, by the way: to show you an error in your
design by catching a condition which should never occur. Unfortunately, an
assert does not _guarantee_ correct design, because it may occur in your
testing that you simply never _get_ a NULL pointer in that portion of the
code. But that doesn't mean your customers won't.)

You need to design your code correctly, avoiding situations where such a
problem could ever occur.

I don't see why you want to be switching between pointers and references in
the first place. The only place I recall seeing such "conversions" is when
I am using pointers, but I'm calling a function in someone else's library
which expects a reference. In that case, I simply dereference my pointer.
If the pointer could _ever_ be NULL, then it's _wrong_ to call that function
in the first place (at least without checking for NULL first).

The question in such a case, then, is: what is the problem, really?

Did I make a design error? If my code assumes that that function _must_ be
called at this point, then I _must_ have made a design error, because I
allowed a NULL pointer to propogate to a place where there must never be a
NULL pointer! Time to rethink my design. Back up and see why the code
allows a NULL pointer to get here.

Alternatively, it may be that it's ok and normal for a NULL pointer to exist
at this point. In that case, my design needs to include an alternative
action for the case when the pointer is NULL. So a regular if statement is
called for, with some other action besides calling that function taken when
the pointer is NULL. Again, this is a redesign, or at least an extension to
my original design.

Notice that in neither case am I using an assert or exception to catch a
problem in testing. It's a _design_ issue at the point in time when I
notice myself writing code to dereference a pointer. Make your decision
then (if not earlier!), not when testing shows a problem, because testing
may _never_ show the problem. The problem is just as likely to bit you on
the butt after you've deployed to the field, when customers call to
complain.

If you feel you need to use assertions or exceptions, remember what they're
for: Assertions help point out design and coding problems, catching
conditions which should _never_ occur. (Well, _hopefully_ catching them!)

Exceptions are for handling _expected_ but exceptional conditions, where
you've got a design in the first place which expects that called functions
might throw, and where someone up higher in the call chain knows exactly
what to do about it. (Again, this belongs in your design stage, not as a
last-minute coding addition to try to protect against the undefined behavior
of dereferencing a NULL pointer.)

-Howard