🚀 go-pugleaf

Tony Cook <tony@online.tmx.com.au> writes:
	...
>I don't see any need to _remove_ the current begin/end idiom - as
>you say it's useful - but to simply supply extra interfaces to
>perform the most common functions in a more compact way -
>specifically, operating on the whole container, and possibly

I will agree on this one -- it IS going to be frequent, and:
	find(container)
IS a distinct enhancement over:
	find(container.begin(), container.end())

>operating from the start of the container to a specific point and
>from a specific point to the end of the container.

But how could you do better here than
	find(container.begin(), specificPoint)
or
	find(specificPoint, container.end())
???


>  vector<int>::iterator searchStart, searchEnd;
>  // ... searchStart, searchEnd set somehow
>  vector<int>::iterator searchPos = searchStart;
>  while (searchPos = find(searchPos, searchEnd)) != searchEnd)
>  {
>    //...process it
>    ++searchPos; // prepare for next one
>  }

>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...?


Alex
--
DISCLAIMER: these are TOTALLY personal opinions and viewpoints, NOT connected
in any way with my employer, nor any other organization or individual!
Email: martelli@cadlab.it                            Phone: +39 (51) 597313
CAD.LAB s.p.a., v. Ronzani 7/29, Casalecchio, Italia   Fax: +39 (51) 597120


---
[ 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. ]