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