"toton" <ab*******@gmai l.comwrote in message
news:11******** *************@p 79g2000cwp.goog legroups.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 "conversion s" 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
