Talk:Virtual inheritance

Logical spectrum of article via keyword/keyphrase counts
The article keyword/keyphrase count (and keywords/key phrase) is listed below. Generating a PDF version of the article and doing a search via Adobe PDF reader version 7 is a good way to quickly find the keywords and how they are used in the article

These counts are from the July 26 2006 version of the article.

These counts are useful to content comparison/replication in other articles dealing with object-oriented language inheritance phenomena.

Some of the words below are not keywords/key phrases but are highly relevant to accurate articulation of the subject matter. They are included to help in comparative analysis of other articles.

Running the same pattern over the C++, C# and Java language specification shows the article (WikiPedia VI article) makes very few assumptions when compared to a formal ISO language spec (as it should as a reference document Vs. an architecture/spec doc).

Note the logical spectrum gives an accurate breakdown of what the core focus of the article is. The same table can be resorted (mannually of course) based on highest count first. This is done at the bottom to show the top dozen logical keys in the content.


 * 010 - keyword
 * 042 - phenomena
 * 252 - inheritance
 * 001 - class inheritance phenomena
 * 150 - virtual inheritance
 * 007 - virtual inheritance phenomena
 * 028 - (VI)
 * 011 - general virtual inheritance
 * 015 - (GVI)
 * 009 - simple virtual inheritance
 * 015 - (SVI)
 * 002 - implementation inheritance phenomena
 * 028 - implementation inheritance
 * 010 - (II)
 * 169 - code element
 * 012 - implementation code element
 * 099 - virtual code element
 * 094 - use context
 * 004 - use context aspect
 * 008 - virtual keyword
 * 020 - virtual control mechanism
 * 012 - (VCM)
 * 006 - diamond problem
 * 001 - inherited class ambiguity
 * 005 - (ICA)
 * 001 - method override ambiguity
 * 001 - (MOA)
 * 011 - resolution inheritance
 * 015 - binding
 * 005 - element binding
 * 002 - language binding
 * 007 - coupling
 * 001 - element coupling
 * 002 - language coupling
 * 037 - aspect
 * 006 - control aspect
 * 001 - specification aspect
 * 003 - polymorphic aspect
 * 004 - use context aspect
 * 006 - semantic
 * 011 - semantics
 * 001 - semantic aspect
 * 007 - conceptual semantics
 * 003 - syntax
 * 002 - syntax mechanism
 * 042 - mechanism
 * 001 - resolution mechanism
 * 026 - control mechanism
 * 001 - binding mechanism
 * 004 - specification mechanism
 * 002 - pattern mechanism
 * 071 - pattern
 * 013 - pattern unit
 * 002 - pattern unit mechanism
 * 009 - SPD pattern
 * 002 - functional pattern
 * 001 - design pattern
 * 001 - performance pattern
 * 042 - mechanism
 * 001 - resolution mechanism
 * 026 - control mechanism
 * 001 - binding mechanism
 * 004 - specification mechanism
 * 002 - pattern mechanism
 * 071 - pattern
 * 013 - pattern unit
 * 002 - pattern unit mechanism
 * 009 - SPD pattern
 * 002 - functional pattern
 * 001 - design pattern
 * 001 - performance pattern
 * 001 - performance pattern

High count list - first 12 counts


 * 252 - inheritance
 * 169 - code element
 * 150 - virtual inheritance
 * 099 - virtual code element
 * 094 - use context
 * 071 - pattern
 * 042 - phenomena
 * 042 - mechanism
 * 037 - aspect
 * 028 - (VI)
 * 028 - implementation inheritance
 * 026 - control mechanism

—Preceding unsigned comment added by Shawn wiki (talk • contribs) 13:33, 26 July 2006 (UTC)

"The solution" does not solve the diamond problem
Unless I'm missing something, the solution does not work if both WingedAnimal and Mammal override eat, as stated in diamond problem. g++ complains as follows:


 * 1) include

class Animal {	public: virtual void eat {		std::cout << "Animal" << std::endl; } }; class Mammal : public virtual Animal {	public: virtual void eat {		std::cout << "Mammal" << std::endl; } }; class WingedAnimal : public virtual Animal {	public: virtual void eat {		std::cout << "WingedAnimal" << std::endl; } }; // A bat is a winged mammal class Bat : public WingedAnimal, public Mammal {};

int main {	Bat bat; bat.eat; }

multiple inh.cpp:31: error: no unique final overrider for 'virtual void Animal::eat' in 'Bat' multiple inh.cpp: In function 'int main': multiple inh.cpp:36: error: request for member 'eat' is ambiguous multiple inh.cpp:15: error: candidates are: virtual void Mammal::eat multiple inh.cpp:24: error:                virtual void WingedAnimal::eat

118.7.198.171 (talk) 08:16, 14 June 2009 (UTC)
 * You're right, the example is horrible in that it sets up a problem that isn't dealt with/solved by virtual inheritance. I've rewritten a new example which I think more correctly demonstrates the problem that virtual inheritance is designed to fix. --Colonel Cow (talk) 17:03, 8 August 2009 (UTC)

Hug? Why would you want to do that????

The problem with such Animal hierarchy: one doesn't know what real problem is being solved! WPcorrector (talk) 05:06, 10 November 2011 (UTC)

problems caused by multiple inheritance?!
I fixed the first paragraph to more exactly explain what virutal inheritance is. It is generally has to do with the inherited incomplete object. The effect on the ambiguity of members is an effect not the source.

Moreover, it is not used to solve any problems caused by multiple inheritance. Multiple inheritance is a language feature that can be used to solve some design problems, it does not and cannot invent design problems. So does virtual inheritance (as a sub-feature of multimple inheritance). It can be said, truely, that abusing a language feature such as multiple inheritance or virtual inheritance (or any other), may result in all sorts of problems (but that a different usage of this word). But that should be put in another article such as Learn design, then learn a programming language, then write code - and not the other way around!. --Itaj Sherman (talk) 15:44, 22 November 2009 (UTC)

Replicated references
There are two references cited in this article. The first link is supposedly authored by Andrei Milea, while the second is authored by Ralph McArdell. However, both references point to the same URL (specifically the article by Andrei Milea: http://www.cprogramming.com/tutorial/virtual_inheritance.html). Therefore, the second reference is not actually adding anything to the article. —Preceding unsigned comment added by 208.65.73.201 (talk) 18:06, 16 May 2011 (UTC)
 * Fixed — Preceding unsigned comment added by 173.196.139.154 (talk) 03:33, 29 December 2012 (UTC)

"representation" nonsense

 * The ambiguity is caused by the way C++ implementations typically represent classes. In particular, inheritance is simply a matter of putting parent and child classes one after the other in memory. Thus,  is represented as, which makes   duplicated (in other words,   owns two different   instances, namely a   and a  ).

Complete non-sense. The ambiguity has nothing to do with representation! Whoever wrote this doesn't understand C++, esp. inheritance, at all and should refrain from writing any article about C++ inheritance.

If you believe that C++ is a "low level language" where the representation of classes is what matters, please actually learn C++ before writing about C++ in WP.

Also please don't complicate this issue even more with slicing, esp. the invocation of implicitly declared copy ctors. WPcorrector (talk) 05:11, 10 November 2011 (UTC)

Inheritance Order

 * Virtual inheritance is a C++ technique that ensures only one copy of a base class's member variables are inherited by grandchild derived classes. Without virtual inheritance, if class  is inherits from both classes   and , and classes   and   both inherit from class  , then class   will contain two copies of  's member variables: one via  , and one via  . These will be accessible independently, using scope resolution.


 * Instead, if classes  and   inherit virtually from class , then objects of class   will contain only one set of the member variables from class.

The order of inheritance doesn't make sense to me. As shown in the UML diagram, D inherits from B and C, B and C inherit from A.--Diaspomod (talk) 11:43, 4 May 2019 (UTC)


 * I've tried to fix this. Can you please check? – Tea2min (talk) 19:32, 4 May 2019 (UTC)