🚀 go-pugleaf

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