🚀 go-pugleaf

f_clerc@effix.effix.fr (Fabrice Clerc) wrote:

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

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

   I agree it is fine to write your own functions -- but not that
such functions ought to be standardised.

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

   Yes. You have a choice to use them, or even write some more :-)

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

   "number of people" isn't a good criteria by itself.
I haven't written this particular function, because it 
doesn't do much for me: I'm getting used to supplying both
begin() and end() off of containers and I find it quite
readable -- personal taste, mind you. There are enough cases
where I am NOT using a range of a whole container that
I like seeing the same form of arguments used everywhere:

   copy(x.begin(), x.end(), out);
   copy(it1, it2, out);

rather than two forms:

   copy(x, out);
   copy(it1, it2, out);

The former COULD have been adopted as standard:

   copy(range(it1, it2), out);

.. but note that "copy()" returns an iterator separate from its 
argument "out". So it seems better to pass the beginning and
ending iterators separately everywhere rather than sometimes
a range object and sometimes not. (to me, anyhow)



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