Re: Templated containers of inherited objects

On Feb 16, 1:05 pm, rpbg...@yahoo.com (Roland Pibinger) wrote:


I think that this comment is misleading. If I understand the point of
the statement, its that using objects that use polymorphism in a
container isn't supported. Because this isn't the case at all.
Although, objects used with the STL must provide certain concepts,
such as default constructibility, copy constructibility et al.

When dealing with class hierarchies, we must pay special attention to
copy constructibility and other concepts because these can lead to
problems such as slicing as noticed by the OP.

Using pointers is a perfectly valid method of fixing this issue.

On the other hand, if Roland meant that "You can't subclass objects
such as std::vector." then he is in fact correct. IIRC, most stl
objects don't provide a virtual destructor. And further, the STL (as
its name suggests) is a library of templates. Using templates with
inheritance is at best tricky.

I'm not sure what the actual standard has to say on this, but g++
4.0.2 won't compile this:

class A
{
    public:
        A() {}
        ~A() {}

        template< typename TYPE >
        virtual void
        echo( TYPE val ) = 0 ;
} ;

The error is:
error: invalid use of 'virtual' in template declaration of 'virtual
void A::echo(TYPE)'

This all makes sense if we think in terms of the (non-standard
dictated) vtable implementation of polymorphism. When we create the
vtable for A, we have no idea how many entries it will have.
Theoretically, it would need to have an entry for every template
instantiation of A::echo(TYPE).

Whats more, this class definition could possibly change after it has
been compiled. Ie, compiled in a library, then some client code calls
A::echo(TYPE) with a type thats not used in the library. Thus the
vtable would change and break all sorts of things.

STL containers,


This is just wrong. A pointer *is* a value. Its a memory address. STL
containers will work just fine with pointers.

Objects on the other hand must provide the required concepts as
mentioned before. The entire point of the STL is to provide a system
that allows for use with any custom type. They'd be pretty pointless
if they could only hold things like int, float, char* et al.

Workarounds exist but with 'Standard' STL there


I'm not entirely certain what 'impedance mismatch' means. Although it
kinda reminds me of studying power amplifiers...

But the point that needs to be made here is that using smart pointers
in a container is not a work around. Smart pointers are a means to
perform resource control. In the case of using pointers, if the only
copy of a pointer to an object is in a std::vector, and then
std::vector::clear() is called, then the objects in it are leaked
(assuming we don't have copies to the pointer anywhere else). Smart
pointers do reference counting ( or some other method ) to determine
when an object should be delete'ed. So when std::vector::clear() is
called, the smart pointers can determine whether or not the object
should be delete'ed and thuse, no memory is leaked.


HTH,
Paul Davis