Re: abstract base class containing class
On Feb 2, 5:34 pm, Noah Roberts <n...@nowhere.com> wrote:
scg_ wrote:
template <class T>
class A {
public:
virtual int size() const = 0;
class iterator;
friend class iterator;
class iterator {
public:
virtual T& operator*() const = 0;
virtual T* operator++() = 0;
};
virtual iterator begin() const = 0; // error
};
This interface is broken in at least two ways. First,
operator++ should not return a T*, but an iterator reference
(return *this after incrementing). Second, you can't use
polymorphism with static objects.
I'm not sure what you're trying to say with that last statement.
Objects with static lifetime can certainly be polymorphic. More
fundamentally, I think polymorphism is more an issue of types,
rather than object lifetime. But I'm pretty sure you're aware
of this, so you must be trying to say something different.
If you want iterator to be polymorphic, and the begin()
function to be able to return a sub, then you need to use heap
allocation and the begin function needs to return a pointer,
reference, or some smart object that can encapsulate the heap
allocation (shared_ptr, auto_ptr, etc). Otherwise, even if
you do adjust begin() to return an iterator you'll run into
slicing and what the client gets will be an A<>::iterator, not
a subclass (in this case that just plain won't compile since
iterator is abstract).
What you really need is the letter-envelope idiom, which permits
"values" to be polymorphic. It works, but it's fairly
complicated, and it has very significant runtime overhead. It
also tends to confuse readers, because value types don't
normally behave polymorphically.
Quite frankly, I doubt you need to do this. The strength of
STL objects is their use of compile time polymorphism.
One can argue whether this is a strength or a weakness. It
certainly reduces flexibility. On the other hand, any idiom
which assigns value semantics to things like iterators more or
less has to do so, or pay an enormous price in terms of
execution speed.
Trying to override that seems to be a lot of work with little
benefit. I've never needed to do it. Doesn't mean you
don't...just that you may not be looking at all available
solutions.
Making STL iterators polymorphic is fighting the system; you
just can't win.
There are cases where polymorphic iterators are useful.
Typically (at least in my experience), they're also cases where
you need reference semantics for iterators. In such cases, you
don't use the STL. You might use C++'s other iterator model,
std::streambuf, but that carries some extra baggage, and has a
number of restrictions (since it was designed to be used in a
special case of iterating only). Or you role your own; a simple
GoF iterator with reference semantics isn't very difficult, and
can trivially be made polymorphic.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
Conseils en informatique orient=E9e objet/
Beratung in objektorientierter Datenverarbeitung
9 place S=E9mard, 78210 St.-Cyr-l'=C9cole, France, +33 (0)1 30 23 00 34