🚀 go-pugleaf

In article <449o3m$17jm@news.doit.wisc.edu>, khan@xraylith.wisc.edu says...
>
>Fabrice Clerc <clerc@gla.ecoledoc.ibp.fr> wrote in comp.std.c++:
>> maybe make containers of pointers a bit easier to use:
>> 
>> o allow "standard" comparison functions to be used with
>>   containers of pointers:
>> 
>>   set<int*,indirect_apply<less<int> > > spi;
>> 
>>   (boy, that sure is synctatic sugar :-)
>> 
>
>I always have and still do contend that if you have pointers in your
>containers, you should revisit the design: if you're storing pointers
>to basic/built-in types, why bother; if you're storing pointers to
>classes either for efficiency/space or for polymorphism, use a wrapper.
>See http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html for
>some rationale and examples of this.
>

I guess you're right (do you wrap _all_ your pointers ?).


>With that out of the way, how about the following: (off the top of my 
>head, so not tested yet)
>
[...]
Yes, I have something along these lines, it works ok.

>
>or you could always do what ObjectSpace does -- define new global fcts
>(eg., less_p which deferences the args before using them).
>
> 
[...]
>
>The real question is whether these "convenience" functions/algos should
>actually be (have been) part of the standard? My personal belief is that
>these are way too specific to programming style and the particular 
>application, and should be left to the user to add to the STL base,
>preferably in a different namespace.
>

But don't you think that commercial versions of the STL will
ship with these convenience functions? I guess they will, because
these functions _are_ useful. And people will use those functions
(at least I will). What does that mean? It means that if I want
to try another implementation, I will have to port my code to that
other implementation, because the convenience functions will be
slightly different.

I'd like to be able to choose a commercial version of the STL
based on the quality of its implementation, not its interface.

Don't get me wrong, I don't think that a standard should attempt
to solve all the problems programmers stumble across. Believe me,
I am fighting that kind of behavior every day (you know: "please
add this to this library, and add this as well because that would
be useful to me, etc"). I just wish that in the case of STL they
had gone a bit further...


>
>regards,
>mumit -- khan@xraylith.wisc.edu
>http://www.xraylith.wisc.edu/~khan/
>

Fabrice
clerc@gla.ecoledoc.ibp.fr
f_clerc@effix.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. ]