jbuck@Synopsys.COM (Joe Buck) wrote:

>it
>seems that vendors are making their own enhancements to
>the libraries, generally in the same direction: to make
>the library somewhat less low-level, to provide cleaner
>interfaces for the very common
>
> algorithm(container.begin(), container.end())
>
>so that one can write something like algorithm(container)
>(in ObjectSpace's case) or container.algorithm() (in
>Rogue Wave's case).

>Perhaps the committee should consider doing a little bit in
>this area, before every library vendor does it differently?

    STL containers are provided in the
Standard Library as a convenience. They're not fundamental
to the architecture. The specification of sequence by
two iterators is, and thats about the end of it.

   Minimalism here is crucial: providing redundant objects
representing iterator pairs makes extension tedious,
and error prone. The convenience provided users by
overloading algorithms on containers (or, providing
equivalent members) is transient and counterproductive:
more advanced use of STL shows many operations are performed
not on containers directly, but on ADAPTED ITERATORS.

   If RW want to upgrade their own library based on STL
ideas, and provide a more OO interface, thats fine:
that may suit their clients; STL is left decoupled
deliberately exactly so library vendors can do this.

>It seems that there are fairly natural interfaces that could
>be provided to cover the common cases where a range that
>is the entire container is to be specified, where the user
>is thinking "sort the container" or "copy container A to
>container B".  If the committee doesn't provide them, they
>will still be there, based on what vendors are already
>doing, but they will be non-portable.

  You're right, but the kind of redundancy above isn't
nearly as important as other considerations.

  For example my STL implementation has a reference counter
in each container to permit use of invasive reference counted
smart pointer classes.

  This is a serious compliance problem: my applications
require the member named "refcnt", so my code will not
work with other STL implementations. Bad. But,the advantages
of invasive reference counting are overwhelming for efficient
automatic memory management of containers.

  So IF I were to propose an extension to C++ I might consider
requiring a public integral data member of each container,
named "refcnt" -- seems more important to effect automatic
storage management than trap a small percentage of silly errors.

  Memory leaks are harder to detect than infinite loops :-)

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

mcorcora@ix.netcom.com (Marian Corcoran) writes:
>     E.  RogueWave to include STL, coming out in Sept.

Rogue Wave is now giving a January 1996 date for STL
inclusion.  See

http://www.roguewave.com/rwpav/products/stdlibwp.htm

for discussion of their plans for including STL support
in their Tools.h++ class library.

Reading that paper, and looking at what ObjectSpace has
done (see http://www.objectspace.com/products/stl/), it
seems that vendors are making their own enhancements to
the libraries, generally in the same direction: to make
the library somewhat less low-level, to provide cleaner
interfaces for the very common

 algorithm(container.begin(), container.end())

so that one can write something like algorithm(container)
(in ObjectSpace's case) or container.algorithm() (in
Rogue Wave's case).

Perhaps the committee should consider doing a little bit in
this area, before every library vendor does it differently?
It seems that there are fairly natural interfaces that could
be provided to cover the common cases where a range that
is the entire container is to be specified, where the user
is thinking "sort the container" or "copy container A to
container B".  If the committee doesn't provide them, they
will still be there, based on what vendors are already
doing, but they will be non-portable.

--
-- Joe Buck  <jbuck@synopsys.com> (not speaking for Synopsys, Inc)
Anagrams for "information superhighway": Enormous hairy pig with fan
      A rough whimper of insanity


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