Re: Diamond Inheritance and STL
On Apr 7, 1:39 pm, "HGal...@teranews.com"
<h...@ga110n7744.freeserve.co.uk> wrote:
I have an application where I have visual elements which are
a: Moving or Stationary, and b: Static or Animated
This sounds like you need the mixin pattern.
//
using namespace std;
//
class element
{
public:
virtual void Paint (HDC hDC);
Just curious, but is it possible that this should be pure
virtual. (Usually, the base class in such patterns only
contains pure virtual functions, but I suppose that there can be
exceptions.)
};
//
class movingElement : public element
{
public:
void Move ();
};
The question here is whether movingElement is a definitive type,
or just a mixin, implementing the "moving" functionality. If
the latter, it should be:
class movingElement : public virtual element
{
} ;
Also, it introduces a new public function. Is it supposed to be
an extension to the interface, or not. (I don't like mixing
partial implementations and extensions to the interface, but
there are times it's justified.)
If you're really thinking in terms of mixins, I like
implementing both alternatives, i.e. also defining a
stationaryElement, even if it is more or less empty. (This, of
course, is related to the concept of extending the interface or
not---a mixin shouldn't normally extend the interface.)
//
class animatedElement : public element
{
public:
void Update (); // get next image in
// animated sequence
};
Same comments as for movingElement.
//
class movingAnimatedElement : public movingElement,
public animatedElement
{
};
One of the reasons I like the idea of having a class for both
alternatives in the mixin strategy is that this can be cleanly
made into a template:
template< typename Movement, typename Animation >
class ConcreteElement
: public Element, private Movement, private Animation
{
// ...
} ;
Again, it's important to understand what you want to inherit,
interface or implementation. I'd avoid using the same
inheritance for both.
This type of solution does introduce a number of additional
classes. I find it cleaner because it separates the concerns,
but YMMV. If I wanted to avoid the extra classes, and rest
close to what you have done, all of the final classes should
inherit virtually from element, i.e.:
class movingElement : public virtual element
{
// ...
} ;
class animatedElement : public virtual element
{
// ...
} ;
class movingAnimatedElement
: public virtual element
, private /* ? */ movingElement
, private /* ? */ animatedElement
{
} ;
(The choice of private or public for movingElement and
animatedElement here depends on whether movingElement and
animatedElement are considered extensions to the interface or
not. Interfaces should be inherited publicly, implementations
privately.)
So far, so good. Now I need a container to display all visual
elements sorted by e.g. Z-Order
//
class elementList
{
protected:
list<element*> m_list;
Just a nit, but std::vector< element* > is probably a better
choice. Unless you want to go directly to std::set< element*,
ZOrderCmp >.
public:
virtual void addElement (element* pEl);
};
Now, when adding all elements into a sorted list
//
void fn ()
{
element el;
movingElement mEl;
animatedElement aEl;
movingAnimatedElement maEl;
elementList elList;
elList.addElement (&el); // ok
elList.addElement (&mEl); // ok
elList.addElement (&aEl); // ok
elList.addElement (&maEl);
Error C2594: 'argument' : ambiguous conversions from 'class
movingAnimatedElement*' to 'class element*'
}
C2594 is defined as "'operator' : ambiguous conversions from
'type1' to 'type1' No conversion from one specified type to
the other was more direct than any other. It may be necessary
to define or specify an explicit conversion."
That's because without the virtual inheritance, you don't have a
diamond inheritance, you have two instances of element in the
object, and it's ambiguous which one's address is wanted.
If I convert maEl to a movingElement, I can't update the
animated image frame; if I convert it to an animatedElement, I
can't move it. And I'd rather not add "virtual void Move ()"
to the definition of element and everything derived from it.
Any help, anyone?
I think the design needs a little bit more thought, with regards
to whether move and update should be part of the base interface,
or form extension to the interface; in the latter case (but that
may be just me), I'd separate the interface from the
implementation. But globally, the only real problem is the lack
of virtual in the inheritance.
--
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