Re: Can't find last element in list
On Apr 27, 3:43 pm, d...@furrfu.com (Drew Lawson) wrote:
In article <1177662609.966340.240...@n35g2000prd.googlegroups.com>
James Kanze <james.ka...@gmail.com> writes:
On Apr 26, 9:05 pm, d...@furrfu.com (Drew Lawson) wrote:
In article <f0qs3n$et...@news.datemas.de>
"Victor Bazarov" <v.Abaza...@comAcast.net> writes:
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 professional answer doesn't depend on the language: you read
the documentation of a function before using it.
As the user of the function, that is what I'd do.
As the writer of the function, which is what I thought Victor was
getting at, I'd go with what is "standard" for the language, and
that does depend on the language.
You mean you were discussing design issues, how to best design
the function.
Of course, you can always write C++ as if it's Fortran77, but I
pity the person who gets to maintain it later.
Don't I know it. There's an awful lot of C++ out there that was
written as if it were C.
The C++ answer seems to be, "why do you need a pointer?"
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.)
Actually, returning a null pointer is probably the most robust
and the easiest to debug. On most implementations,
dereferencing a null pointer will make the program go boom
immediately. Using an out of bounds index or a one-past-the-end
pointer will usually just return garbage; your program ends up
outputting wrong values, and you have to figure out why.
By "containers and sucscripts" I was intending to reference
std::vector<>.at(), which I believe will throw an exception if given
a bogus index.
Except that 1) that's not what you want, and 2) no one uses
vector<>::at() anyway. The implementations of std::vector I use
will also core dump if you access the vector with an invalid
index or iterator. And in general, one past the end is the
idiomatic way of signaling that you haven't found what you were
looking for.
If, however, the function is defined to return a pointer, and is
called with C-style arrays, it's already not idiomatic C++:-),
it's idiomatic C, and idiomatic C would be to return a null
pointer. Which is also more robust.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34