Re: vtable with virtual base class?
On Dec 12, 6:35 pm, Dave Johansen <davejohan...@gmail.com> wrote:
On Dec 12, 1:47 am, James Kanze <james.ka...@gmail.com> wrote:
On Dec 11, 6:12 pm, Dave Johansen <davejohan...@gmail.com> wrote:
Thanks for the response and it answered exactly what I was
looking for. I agree that the penalty is small and "worth
paying" to avoid the duplicated code, when it's REALLY
necessary and there's not a better design to handle the
problem.
I'm not sure what you mean by "really" necessary? Anytime
inheritance is being used to extend an interface, you should
probably use virtual inheritance. The cost is generally
negligeable, and virtual inheritance will be more robust
with regards to different client use.
In this regard, I'd suggest reading Barton and Nackman. They
discuss the various design trade-offs in detail.
I understand the logic behind recommending to just make all
inheritance virtual (similar to the recommendation of making
all destructors virtual), but I've never agreed either of
those being a good rule for general use.
I don't understand the logic behind recommendation to just make
all inheritance virtual, and I didn't recommend it. I said that
when you define an interface which extends another interface,
you should use virtual inhertitance. In most other cases I've
encountered, such as mixins, it's obvious up front that you need
virtual inheritance, so you don't need a guideline whether to
use it or not.
And I'd still suggest you read Barton and Nackman; they treat
the issues in some detail, including the cost aspects.
Also, I realize that this is just one compiler and an extreme
example, but according to this post
(http://www.codesynthesis.com/~boris/blog/2008/04/17/virtual-inheritan...=
)
the cost is not all that negligible.
I couldn't deduce that from the article. There was a lot of
hand waving in it, but no concrete facts.
Also, just for anyone else who may stumble along this thread.
I found this article
(http://www-plan.cs.colorado.edu/diwan/class-papers/mi.pdf)
and Section 7 actually discusses the logic behind the use of
virtual base classes to resolve the "diamond problem"
I couldn't find any mention of a "diamond problem" in it.
(I've found mention of a "diamond problem" is often a symptom
that the author really doesn't understand the issues that well.
The fact that you have a diamond in your inheritance graph is
not a problem; it is, in fact, perfectly normal.)
He doesn't not use the term "diamond problem" but Section 7
explains the issue exactly and describes the motivation for
why C++ chose the methodology that it did.
He doesn't use the term "diamond problem" because there isn't
any problem, except in people's imagination.
--
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