Peter Paul Chase wrote:

> I seem to have touched a nerve--sorry.  I'm interested to
learn that D will
> provide the functionality of the STL in some other form.
Quite an undertaking!

I read somewhere that there is being thought about integrating
templates and
possibly STL... However, I personally think STL has a couple of
design mistakes.
1.    The interface is not the same for all collections.
2.    There is no way to chose for compile time or runtime
polyphormism. All it can
do now is compile time polyphormism which basically leaves the
root of the original
C++ with runtime polyphormism...

Check some reading on news://forums.borland.com/borland.public.cppbuilder.language/ subject "D Programming Language spec"

Basically it comes down to that I think there should have been a
design (simply)
like:

class  _STLVirtual
{
    protected :
        _STLVirtual ();

    public   :
        virtual        add    ( .. )    = 0;
        virtual        erase    ( ... )    = 0;
        virtual        begin    ( ... )    = 0;
        virtual        end        ( ... )    = 0;

        // ...
};

class  _STLEmpty
{
};


Than:

template < class T, class Base >  class  vector : public  Base
{
    public    :
        add ( .. );
        erase ( ... );
        begin ( ... );
        end ( ... );
};

Than if you want compile time polymorphism:

// Should not really hurt as _STLEmpty is empty, i.e. does not
have any (virtual)
members.
vector < int, _STLEmpty >        array0;

If you want run-time polymorphism:

vector < int, _STLVirtual >        array1;
list < int, STLVirtual >              list1;


void DoSomethingWith ( _STLVirtual  *coll )
{
    // ...
}

Do you want extre members in run-time polyphormism. Derive a
class from _STLVirtual
and use that as base class:

class  My_STLVirtual : public _STLVirtual
{
    public    :
        virtual        MyExtraMembe    ( ... );
};


vector < int, My_STLVirtual >        array2;
list < int, My_STLVirtual >            list2;

void  DoSomethingWithMyStuff ( My_STLVirtual  *coll )
{
    // ...
}

Of course with STL as it has been designed this is a problem as
equally named
members in the different collection templates have different
parameters and return
types. However I think this could have been resolved in the
design...
Having the same return types and parameters for compile time
polymorphism only
would make things easier for implementation anyways... (Than you
don't have to
think... I geezh how did I get the data out of this one?!)

Jan

Or... if you really want that functionality in C++, you could just write some wrapper classes and wrap up the STL classes, and then you'd have your runtime polymorphism.

Why should that be part of the standard?

The interfaces are different because the containers are different
(but they are the same where the functionality is the same; begin()
and end(), for example). You really don't want to pop_front() on a
vector. If you need pop_front, use a list. Having pop_front() on
every container and using it in code which doesn't know what kind of
container it's being applied to would be, dare I say, the opposite of
an intelligent design.

It seems you want to use runtime polymorphism for the sake of using runtime polymorphism..