Re: Can't find last element in list

From:

"Victor Bazarov" <v.Abazarov@comAcast.net>

Newsgroups:

comp.lang.c++

Date:

Thu, 26 Apr 2007 15:48:03 -0400

Message-ID:

<f0qvlj$mf6$1@news.datemas.de>

Drew Lawson wrote:

In article <f0qs3n$ete$1@news.datemas.de>
"Victor Bazarov" <v.Abazarov@comAcast.net> writes:

Lawson wrote:

[..]
Common and hazardous pattern for that, assuming that you *have* to
return a pointer, is to return a null pointer for "not found." Just
make sure that any caller is testing for null.

And here is the kicker -- there is no way to "make sure that any
caller is testing". It's the caller's responsibility. All you can
do is document the proper way of using your function. This is
especially important for library designers. It's easy when you
design/implement both the function and the code that calls it.
What if you don't?

The C answer is culture -- learning that anything that returns a
pointer can return NULL. Here be dragons.

The C++ answer seems to be, "why do you need a pointer?"

It really has nothing to do with pointers/indices/anything else.
It's the inability in either language to force the caller to use the
returned value in the way it is intended to be used.

Nothing prevents me from calling 'printf' without ever assigning or
checking the return value, although it is known that the return value
type is 'int' and what the number means.

For the OP's task, I'd lean more toward returning an index, but
that has the same out-of-bounds issues for the failure value. But
a subscripting exception is easier to debug than rogue-pointer
memory corruption. So this case has me sold on containers and
subscripts. (Still making the C --> C++ cultural shift.)

That's not as generic as returning the "end" value (just like 'find'
and related algorithms from the Standard Library do).

V
--
Please remove capital 'A's when replying by e-mail
I do not respond to top-posted replies, please don't ask