🚀 go-pugleaf

In article <MATT.95Sep23125702@Austern> martelli@cadlab.cadlab.it
(Alex Martelli) writes:

|> Tony Cook <tony@online.tmx.com.au> writes:

    [...]
|> >The test here should be 'did we find it' - not 'are we at this point
|> >yet' - find 'knows' where the end of the range is - why can't it
|> >report whether or not it was successful without us having to supply
|> >one of it's parameters again?

|> Because, I guess, there is no "null" value for every sort of
|> iterator -- one that could only be used for automatic conversion
|> to bool returning false, while every other iterator would convert
|> to true.  This is a distinct convenience with pointers and one
|> of the most common C idioms, of course.  If there was a "null",
|> then it would seem to me to be the natural value to return from
|> an iterator-returning function that "fails" (in a "soft" sense,
|> not in an exception-raising one).  "Null" would also be a natural
|> for initialization of iterators, etc, again in analogy with
|> pointers.  I assume there were solid reasons not to guarantee
|> the existence of "null iterators" for every kind...?

One nice solution comes from Barton and Nackman: the Fallible class
template.  It is also applicable to pointers, and IMHO, results in a
much cleaner interface than using null pointers.

The problem, of course, is that although the interface is much
cleaner, the resulting code, at least with today's compilers, will be
significantly slower, since it replaces returning a pointer with
returning a class.  For functions like find, which contain a loop, I
seriously doubt that this would make a serious difference, though.
And of course, in the cases where the iterator is already a class,
the difference is negligible.  (I would hope that such cases will be
the overwhelming majority.)

In many ways, I think it might be better if the STL algorithms used
Fallible.  But given the schedule, and the time constraints, I don't
think it would a good idea to introduce this change now.  (I wish I'd
paid more attention to library issues, and thought of this,
earlier:-(.)
--

James Kanze         Tel.: (+33) 88 14 49 00        email: kanze@gabi-soft.fr
GABI Software, Sarl., 8 rue des Francs-Bourgeois, F-67000 Strasbourg, France
Conseils en informatique industrielle --
                              -- Beratung in industrieller Datenverarbeitung
---
[ comp.std.c++ is moderated.  Submission address: std-c++@ncar.ucar.edu.
  Contact address: std-c++-request@ncar.ucar.edu.  The moderation policy
  is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]