Re: Diamond Inheritance and STL
* James Kanze:
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.)
Yes, at this point it seems that you have understood this correctly, provided
that by "same" you mean overrides of the same virtual function.
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.
At this point, however, it seems that you haven't understood anything.
That makes it difficult to help you.
It might be that actually trying to implement a common Paint for two different
classes, one of them providing animation, might help, but I'm not sure whether
lack of understanding of that is the problem.
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?
See above.
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.
There are more than one concrete C++ problem in the code presented. For example,
lack of implementation of a member function. And so on. It would just be silly
to point out any particular of those things as "the answer". Even if one of
those things is being actively fished for, with a few dangling odds and ends
(e.g. the "STL" in the article's title) so that one to a large degree suspects a
reformulated homework assignment. Instead, the thing fished for should IMHO be
pointed out is most probably /not/ a solution to the problem as presented here.
Cheers & hth.,
- Alf
--
Due to hosting requirements I need visits to <url: http://alfps.izfree.com/>.
No ads, and there is some C++ stuff! :-) Just going there is good. Linking
to it is even better! Thanks in advance!