🚀 go-pugleaf

In article <MATT.95Sep9110458@physics10.Berkeley.EDU>,
John Max Skaller  <maxtal@suphys.physics.su.oz.au> wrote:
>
>   Unfortunately, there are some misconceptions about STL.
>One is that is OUGHT to be "user friendly".
>
>  Nope. STL is a LOW LEVEL TOOLKIT, akin to the ISO C Standard
>Library. For example "copy()" is equivalent to "memcpy()".
>Now, you wouldn't recommend using "memcpy()" in the middle of
>an applications program, would you???
>
>  To make STL into a "user friendly" library is a silly idea.

Nope. The notion that STL should NOT be user friendly is a silly idea.
IMHO, there is never an excuse for a poor interface. Even if STL
is a low level toolkit, there is *nothing* that precludes
it from being easier to use. Look at what ObjectSpace is doing with
some of their extensions. It doesn't require all that much thought
and effort to make STL significantly easier to use in many ways.


>Instead, the idea is to use STL to implement a completely separate
>application library.
>
>  For example, consider the type "SET OF T". Would you use 
>the STL set container for this?? You have to be kidding!
>
>  template<class T> class MathSet {
>    set<T, less<T> > data;  // USE STL to implement robust point set
>   public:
>     MathSet() {}
>     ...
>     friend bool operator < .... // note: NOT STL compare!
>     Mathset operator | ..... // Union
>     Mathset operator & ..... // Intersection
>     ...
>     .. getFirst()const { if(data.empty()) throw EMPTYSET().. }
>   }
>
>This is what I want from a set ADT. Implementing it is EASY
>using STL -- and THAT is the purpose of STL.
>

Implementing it is still ERROR PRONE using STL. That's a major complaint
against STL, and the above example does nothing to answer that complaint.
And the above wrapper code still needs to be implemented; and more errors
will creep into the implementation than otherwise just because STL is
so hard to use.

Moreover, you have got to be kidding if you are saying that all uses of
STL containers should be wrapped up within other ADTs! Things are never
so black and white in practice. But if such wrappers were being written
for each and every use of the STL containers, it would become even more
imperative to make STL less error prone; there would be simply no
justification for making the job of implementing those wrappers harder
than it should be.

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

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.


>If you're getting bored writing
>
>   find(longContainerName.begin(), longContainerName.end() ...... )
>
>.. you're probably using STL the wrong way.
>     
>BTW: Continue to do so! The only way to discover how to use
>something well probably entails learning how to use it badly too.
>
>I've had exactly the same kinds of problems -- but I have to
>attribute them to my own level of comprehension, not STL.

Unfortunately, I suspect STL's usability problems transcend the degree
of comprehension. IMHO, if it is not improved, the difficulty of using
STL will lead to more errors than otherwise even after a certain
proficiency is achieved. [Similar to a programmer experienced in both
assembly language and C++  making more errors programming in assembly
than in C++ (some may actually dispute that) just because programming in
assembly language is inherently more error prone.]

-- 
Ajay Kamdar        |    Email: ajay@lehman.com    |    Standard Disclaimer 
Lehman Brothers    |    Phone: (201) 524-5048     |

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