Re: Diamond Inheritance and STL
On Apr 7, 2:17 pm, "Alf P. Steinbach" <al...@start.no> wrote:
* HGal...@teranews.com:
I have an application where I have visual elements which are
a: Moving or Stationary, and b: Static or Animated
//
using namespace std;
//
class element
{
public:
virtual void Paint (HDC hDC);
};
//
class movingElement : public element
{
public:
void Move ();
};
//
class animatedElement : public element
{
public:
void Update (); // get next image in
// animated sequence
};
//
class movingAnimatedElement : public movingElement,
public animatedElement
{
};
So far, so good.
Well, no. You have two distinct base class objects of type
'element', one belonging to movingElement and on to
animatedElement. So if you try to call 'Paint' on a
movingAnimatedElement the compiler will report an ambigious
call: did you mean to call the movingElement Paint or the
animatedElement Paint?
Actually, the only Paint I see is element::Paint. The question
is whether to call movingElement::element::Paint or
animatedElement::element::Paint. The same function, but on a
different object. (I'm also willing to bet that in the actual
code, Paint is overridden in the most derived class.)
And, noting that it doesn't make much sense to call *both*
(which could be arranged in the final bottom level class, but
isn't practically meaningful), you have a design level
problem, not just a C++ implementation problem.
Bullshit. About the only "problem" with the design is that
there doesn't seem to be a clear separation of implementation
and interface, and while I tend to insist on that, I'm not sure
that it's universally recognized as essential.
Adding "virtual" in the inheritance chain is /not/ a solution
of that design level problem -- for with 'element' a virtual
base class you still have the Paint problem.
What Paint problem?
Thus, the resolution hinges on what functionality you really
have in movingElement and in animatedElement.
I.e., does it really make sense to combine these two via
multiple inheritance (I think not, but could be, depending on
what they really are).
It probably does in some way. Whether he's found the optimal
way or not depends on factors we don't really know.
[...]
It's not a C++ problem, the solution is not "virtual"
inheritance,
There is a concrete, C++ problem, to which the solution is
virtual inheritance.
it is a design level problem, where at first I think it will
be helpful for you to focus on exactly what a Paint call on a
movingAnimatedElement should result in.
He mentionned "diamond inheritance" in the subject line, which
makes it fairly obvious that he only wants a single instance of
element in the object. And Paint() should be called on that
instance. The open design questions are more along the lines
how he wants to apply Move() or Update() when all he has are
element*, and whether Move() and Update() can really only have
one possible implementation (i.e. whether they should be virtual
or not).
--
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