🚀 go-pugleaf

In article <4443c0$c0l@oznet03.ozemail.com.au>, maxtal@suphys.physics.su.oz.au says...
>
>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.
[...]
>
>    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.
>

so, you agree :-)

ok, suppose bob writes a small library which uses the STL.
no problem, bob's convenience functions are shipped with the
library and are placed in a namespace. tom also writes a
library which also uses the STL and also has convenience
functions in a namespace.

now, what happens if I want to build an application using both
libraries? I end up with at least two set of convenience functions
(three if I have mine) doing basically the same thing.

imho, if a lot of people end up writing the 'same' convenience
functions, these convenience functions should be placed in a
standard. the question is, what is "a lot of people" ?

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

Fabrice Clerc
f_clerc@effix.fr
clerc@gla.ecoledoc.ibp.fr


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