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

martelli@cadlab.cadlab.it (Alex Martelli) wrote:
>
>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())

    I DON'T agree. 

    It is crucial for orthogonality that the algorithm interfaces
are isolated from any notion of containers -- which is 
what the STL iterator architecture is for.

             ITERATORS
               ^    \-------------\------\---------... 
             /       \             \      \ 
            /         V             V      V
      ALGORITHMS     CONTAINERS DEVICES PROCESSES

    Providing standard algorithms taking container arguments
would destroy the essential independence of the notions
by introducing direct coupling. The _indirection_ provided
by iterators is what makes STL work so well.

    What makes STL such an excellent library is the
way iterators are used to interface containers and algorithms
by contracts on the intermediaries that service both --- iterators.
This leads to predictable orthogonal combination -- where
predictable refers not only to correctness, but also performance.

    There is nothing wrong with writing convenience
functions like "find(container, value)" --- the very ability to
do so in a few lines of code --- in several different ways ---
is exactly why this should NOT be standardised.
Put such a function in your own namespace, to avoid clashes.

-- 
John Max Skaller               voice: 61-2-566-2189
81 Glebe Point Rd              fax:   61-2-660-0850
GLEBE NSW 2037                 email: maxtal@suphys.physics.oz.au
AUSTRALIA                      email: skaller@maxtal.com.au
---
[ 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. ]

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