Re: An suggested extension

[Branko Cibej <branko.cibej@hermes.si>]

scleary@jerviswebb.com wrote:

> The extension suggested above is the first that I have thought of.  It was
> originally conceived (though not implemented) when I was writing my own
> vector class from scratch, having been fairly disgusted at what other STL
> libraries offered.  It was needed (though not used) a few weeks later when I
> had a CPU-intensive program (containing vectors of vectors of
> user-defined-types-containing-vectors, etc.)  that suffered an approx. 20x
> speed decrease because it was not implemented (I got around it in my program
> by declaring vectors of auto_ptr's of vectors).

And it worked? auto_ptr does not meet the CopyConstructible  (20.1.3
[lib.copyconstructible]) and Assignable requirements; instantiating a vector
with auto_ptr is undefined.

> There are a few other extensions I would like to see in the completed
> library; for example: a member function to return a pointer to the
> underlying array in a vector (named __ptr),

*If* the underlying representation of vector is an array (not requred, AFAIK,
but see http://anubis.dkuug.dk/jtc1/sc22/wg21/docs/lwg-issues.html#69), then you
can use

     vextor<int> v;
     // ...
     int* array = &v[0];

> a singly-linked-list class
> (named __sll), and a few others that I think about from time to time.

That might be a nice project for Boost (http://www.boost.org/), but I don't
think it should be part of libstdc++. IMHO, even the hashed containers from the
SGI STL don't belong in the standard library implementation; or at least not in
namespace `std'.

--
Branko Čibej                 <branko.cibej@hermes.si>
HERMES SoftLab, Litijska 51, 1000 Ljubljana, Slovenia
voice: (+386 61) 186 53 49   fax: (+386 61) 186 52 70