[... snip ...]
>
> This is a very practical approach, the only problem is that the
> holding class stl_pointer<T> is not connonical (sp?).
>

Meaning that it seems to combine two concepts into one name? Yes, although
in another sense it is just a specialization of pointer, like smartPointer.
What unnerves me is why this class isn't part of the STL. I feel like there
must be something I don't see, because it's otherwise a trivial class to
write ... right? (nervous grin) ...

[ ... snip ...]

>
> The STL defines containers to type T because they are more generic than
> indirect containers. Indirect containers work only with pointers there
> is no way to simulate direct conatiners, at least I don't know of a way to.
> But with direct containers indirect containers can be implemented.
>

I guess I don't see the genericity when all ordered containers fail to work
when using pointers to T, or more to the point, when storing a list of
objects derived from T. My first impression is that I'd rather have that
than know that when I say "store objects of type T" that the container
actually stores them directly. Why should I care about how they're stored
as long as I get back what I asked for? No? Comments?

> Harry E. Miller
> unicorn@uxh.cso.uiuc.edu
>

Thanks for your response,
-Dan

Daniel Yoder <dyoder@pencom.com> writes:


>The STL stores objects, not pointers to objects. I thus cannot
>say:

> List<BaseClass> aList;
> aList.push_front(aSubClassObject);

>and hope to get out the object I put in. In other words, given a class
>hierarchy, I cannot create a list of objects that belong to that hierarchy
>but may be different from the base class.

>First, is this correct?

You can do the following:

     list<BaseClass *> alist;
     alist.push_front(new aSubClassObject);

The only problem is that the operators work on the pointers not the
objects.

>Second, assuming it is, how can the STL be used in this way? The obvious
>solution is to create a class that stores pointers to the base class
>but provides the interface required by the STL (i.e., ==,<) and the
>standard pointer operations. In other words, an STL-aware pointer class.

>Is this the best approach?

This is a very practical approach, the only problem is that the
holding class stl_pointer<T> is not connonical (sp?).

Another approach is to derive an indirect container class from the original.

   class ilist<T, Allocator> : public list<T *, Allocator>

One problem here (among many) is that every container would need to do
this for completeness.
Also this violates the spirit of STL. To provide a consistant interface
to containers and algorithms which is efficient and as simple as
possible.

>Finally, why exactly doesn't the STL simply store pointers to T instead
>of storing Ts directly? This seems to address the problem, but I must be
>missing something.

The STL defines containers to type T because they are more generic than
indirect containers. Indirect containers work only with pointers there
is no way to simulate direct conatiners, at least I don't know of a way to.
But with direct containers indirect containers can be implemented.

Harry E. Miller
unicorn@uxh.cso.uiuc.edu