I've been using the STL a little recently and can't really call
myself an expert - but I've found that always typing in the
container's name up to three times for a find or twice for other
actions is getting a little error-prone, for example:

 // check if already there
 vector<int> myVector; // this is a _short_ name
 if (find(myVector.begin(), myVector.end(), someInt)
   == myVector.end())
 {
   // not there
 }

I find this more than a little error-prone, why isn't there
something like:

 template <class Container, class Item>
 bool find(Container &c, Item const &v, Container::iterator &i)
 {
     i = find(c.begin(), c.end(), v);
     return i != c.end();
 }

So the above becomes:
 Container::iterator i;
 if (!find(myVector, someInt, i))
 {
   // not there
 }

One argument against this is 'the programmer can write their own' -
but this is true for most things - the libraries are there to
provide a useful (and hopefully less error-prone) implementation so
the programmer doesn't have to write their own.
--
        Tony Cook - tony@online.tmx.com.au
                    100237.3425@compuserve.com

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

In article <DED5p2.I2I@online.tmx.com.au>,
Tony Cook <tony@online.tmx.com.au> wrote:
>I've been using the STL a little recently and can't really call
>myself an expert - but I've found that always typing in the
>container's name up to three times for a find or twice for other
>actions is getting a little error-prone, for example:

 [ Example and suggested alternative ellided ]


Join the club(: You will find many who will agree that STL is
error prone to use. I am sure it's a cool and efficient design,
but IMHO not enough attention has been paid to make it easy to use.


>One argument against this is 'the programmer can write their own' -
>but this is true for most things - the libraries are there to
>provide a useful (and hopefully less error-prone) implementation so
>the programmer doesn't have to write their own.

I couldn't agree more.

Even before the ink is dry on the DWP, commercial vendors of STL
implementations are already extending STL in incompatible ways to fix
these STL usage problems. For example the extensions of two of the STL
vendors, ObjectSpace and RogueWave, are sufficiently different from each
other to prevent code written using one library to be easily ported to
the other. Each approach to extending STL to make it more user friendly
has merit to it and none of them is clearly the only correct way.

If incompatible commercial extensions rather than STL out-of-the-box is
what the programming community is going to largely use, then many of the
advantages of standardizing on STL would be compromised.

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

I would say in your example:

        template <class Container, class Item>
        Container::iterator find(Container &c, Item const &v)
        {
            return find(c.begin(), c.end(), v);
        }

So the above becomes:
        Container::iterator i = find(myVector, someInt);
        if (!i)
        {
          // not there
        }


Generally: all global functions from algobase, which takes two pointers
(start and finish iterators) should have overloaded 'brother'-function
without these arguments to make operation on all elements of the
container (most usefull case).



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

ajay@lehman.com (Ajay Kamdar) wrote:
>In article <DED5p2.I2I@online.tmx.com.au>,
>Tony Cook <tony@online.tmx.com.au> wrote:
>>I've been using the STL a little recently and can't really call
>>myself an expert - but I've found that always typing in the
>>container's name up to three times for a find or twice for other
>>actions is getting a little error-prone, for example:
>
> [ Example and suggested alternative ellided ]
>
>
>Join the club(: You will find many who will agree that STL is
>error prone to use. I am sure it's a cool and efficient design,
>but IMHO not enough attention has been paid to make it easy to use.

>
>>One argument against this is 'the programmer can write their own' -
>>but this is true for most things - the libraries are there to
>>provide a useful (and hopefully less error-prone) implementation so
>>the programmer doesn't have to write their own.
>
>I couldn't agree more.
>
>Even before the ink is dry on the DWP, commercial vendors of STL
>implementations are already extending STL in incompatible ways to fix
>these STL usage problems.


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


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.

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

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.

:   To make STL into a "user friendly" library is a silly idea.
: Instead, the idea is to use STL to implement a completely separate
: application library.

Indeed. STL is a low-level toolkit.

However, IMHO it is NOT a silly idea to expect that there be a STANDARD
for a high-level container library that people actually use in their code.
A standard for a low-level toolkit is pretty uninteresting. What we have
with STL is a low-level standard that everyone needs to make useable, in
incompatible ways. Now THAT is silly.

Could you imagine if the draft standard just gave us the basic_string<T>
template and invited each of us to derive our own user-friendly string class?

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

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