🚀 go-pugleaf

This is a rather interesting thread started by Tony Cook in c.std.c++
on whether STL is error-prone or not. Ajay Kamdar seems to agree, and
he also points out something that is quite troublesome to me as well --
commercial vendors adding extensions "before the ink is dry on DWP".
John Max Skaller, on the other hand, claims that STL is designed to be
a low-level toolkit that app programmers would build on and it does not
necessarily have to be "user-friendly". Since I have a vested interest
in the welfare of STL, I'd like to take this discussion further and
find out what people really want out of STL and possibly come up with a
feasible solution that builds on STL (I personally include stl includes
via "stl/include", where the include file wraps the appropriate stl
include file and adds my own simplified algorithms -- such as deleting
a sequence/map and such).

1. What are the various things that you have find to be error-prone?

2. What kind of changes would you like to see in the interface to the
   STL algorithms? The thread started with Tony Cook using the begin/
   end iterator in find algorithm (which I consider essential since I 
   do partial searches all the time) as an example if I remember
   correctly. Cook suggests find() return a bool and modify the iterator 
   argument ... 

3. Container member functions -- any new members that you think "ought"
   to be added? When it comes to STL, I tend to favor not touching the
   container classes and rather favor adding global fcts ala algo.h.

4. Member functions that are also available as algorithms: eg., list<T>
   provides a sort member (uses '<' relation), but STL also provides
   a generalized sort() algorithm where you provide your custom 
   comparator. Is the list<T>::sort() necessary? If so, why?

5. Verbosity: There was a thread few months ago about verbosity in using
   STL containers and iterators. I have cases where each iterator type
   has to be typedef'd just so I can fit the decl in a reasonable width
   line. I remember someone** proposing some typeof() member to return 
   the correct type of iterator so we don't have to do the following:

   map<string, map<string, list<list<point> > >::const_iterator =
       polygon_map.begin();
    
   And this is one of the short ones in my CAD library.
    
   ** I wish I'd saved the article or remembered who it was.

6. Understanding how STL manages storage: In the past 6 months or so, 
   I've received (and answered quite a few!) about 150 mail messages 
   asking about STL storage management. Is it really that hard to
   understand? What kind of examples would make it clear?

7. What kind of documentation would make using STL easy (easier?)? 

8. your turn ...


Ajay Kamdar <ajay@lehman.com> wrote:
>[Note: Check out the "C++ Tradeoffs" article by Ellis and Carroll in
>  the September '95 issue of the C++ Report for a good discussion of
>  a topic some what related to whether to use a STL container directly.]
>

OK article, but I didn't see a whole lot beyond common sense :-)

>Container classes are needed both in the interface and implementation
>of C++ programs at all levels. If STL is being positioned to NOT fill
>the need for a standard general purpose container library that can be
>used at all levels of C++ programming, then IMHO STL shouldn't even be
>in the standard.

No high level toolkit designed by a committee is going to make everybody
(or even a reasonable population) happy! I would much rather have the
higher level toolkit built on top of STL as a separate package, and if
there is enough interest (and input), I might actually do one of these
(it'll be free of course).

regards
mumit -- khan@xraylith.wisc.edu
http://www.xraylith.wisc.edu/~khan/
http://www.xraylith.wisc.edu/~khan/software/stl/STL.newbie.html

ps: Apologies to moderators about botched attempts in posting this, esp
about the misattribution. At least now I know that you guys actually read 
these :-)
---
[ 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. ]