Talk:Virtual inheritance

C/C++ Unassessed

	This article is within the scope of WikiProject C/C++, a collaborative effort to improve the coverage of C and C++ topics on Wikipedia. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks.C/C++Wikipedia:WikiProject C/C++Template:WikiProject C/C++C/C++
???	This article has not yet received a rating on Wikipedia's content assessment scale.
???	This article has not yet received a rating on the importance scale.

Archives

Archive 1

Archive 2

This page has archives. Sections older than 90 days may be automatically archived by when more than 5 sections are present.

Article core concept keyword list

The full keyword for the article subject is;

virtual inheritance phenomena

The full keyword list for the major core concepts in the article is;

code element
virtual code element
implementation code element
virtual control mechanism
use context (of the virtual code element)
parent use context (of the virtual code element)
client use context (of the virtual code element)
general virtual inheritance (parent use context)
simple virtual inheritance (client use context)

The support concepts that provide the article foundation are;

object oriented languages
language binding
language coupling
inheritance
lines of inheritance
forms of inheritance
specification mechanism
control mechanism
polymorphic mechanism

The incidental concepts that help articulate/contrast the article subject are;

type polymorphism
implementation inheritance
resolution inheritance

The OOL artifacts that help articulate/contrast the article subject are;

object
class
interface
method
abstract method
default virtual method
event
bool

— Preceding unsigned comment added by Shawn wiki (talk • contribs) 16:21, 28 July 2006 (UTC)[reply]

Clean up suggestion

— Preceding unsigned comment added by BenFrantzDale (talk • contribs) 00:46, 27 June 2006 (UTC)[reply]

The following suggestions seek to improve the articulation of the statements noted by Ferdinand Pienaar.

1-org

It allows for a derived object to be used as its base object ...

1-new

Virtual Inheritance (VI) is a fundamental feature of most object-oriented languages. Virtual Inheritance allows for a derived object (the child) to be used by the base object (the parent).

In Virtual Inheritance the child inherits ONLY the specification of the method

defined in the parent. As such the child is FORCED to IMPLEMENT the functionality specified in the signature of the abstract method.

Virtual Inheritance (VI) is contrasted with Implementation Inheritance (II) (link) where the child (the derived object) inherits an IMPLEMENTATION of a function defined by the parent (the base object).

A 'pure abstract method' (link) is one defined by the parent with no 'default implementation' (link).

Pure abstract methods are the definitive expression of Virtual Inheritance as they embody the forced implementation in the child by the specification in the parent.

Pure abstract methods are 'signature only' specifications which leave the implementation to the child. the signature specification (of the abstract method) is the mechanism that allows the parent to call the child without knowing the details of the child's implementation of the parents specification.

Virtual inheritance is the core impetus for Interfaces (link). With Interfaces a child inherits ONLY the specification and NOT the implementation of a method.

Note that in some languages a virtual method CAN OPTIONALLY provide a default implementation (link) of a virtual method. This does not detract from the semantic meaning of Virtual Inheritance which is the ability of the parent to call child implementation.

Note that in cases where a default implementation is provided by the parent the

current casting context will determine which implementation (child or parent implementation) is used.

Note also that in Type Polymorphism the child may use both its

implementation (defined in the child code body) and the parents implementation (of the virtual method) in implementing the child's version of the target functionality.

The pure abstract method and forced implementation are what distinguish Virtual Inheritance (VI)

from 'Type Polymorphism'.

2-org

C++ has two uses virtual inheritance to solve both disambiguity problems caused by multiple inheritance and virtual method overriding.

2-new

C++ has two intentions in its use of Virtual Inheritance; To solve both (1) ambiguity problems caused by multiple inheritance and (2) virtual method overriding.

3-org

C++ has two uses virtual inheritance to solve both disambiguity problems caused by multiple inheritance and virtual method overriding.

3-new

C++ has two intentions in its use of Virtual Inheritance; To solve both [1]

ambiguity problems caused by multiple inheritance and [2] virtual method overriding. The ambiguity problem (link) occurs when the compiler must select one of many class candidates for the inheritance. The diamond problem (link) is a well known example of the ambiguity problem.

4-org

Normal method overriding is limited to the context of the objects current casting.

4-new

Normal method overriding is limited to the context of the object's current casting.

I just noticed that the Multiple Inheritance WikiPedia page has a link to this page (Virtual Inheritanc).

I highly recommend that a change be put in to place a 'See Also' section that provides a link to both the Interface Page and the Multiple Inheritance page.

—Shawnk

To clarify why Type Polymorphism is a superset of Virtual Inheritance I suggest the following changes to my earlier suggestion.

If no one has any objections I will incorporate these changes this weekend into the Virtual Inheritance definition for general review.

—Shawnk

PS. I will try to contact the other authors/commenters via email to coordinate with them on this.

[1-org]

The 'pure abstract method' and 'forced implementation' are what distinguish Virtual Inheritance (VI) from 'Type Polymorphism'.

[2-new]

The 'pure abstract method' and 'forced implementation' are what distinguish Virtual Inheritance (VI) from 'Type Polymorphism'.

Thus 'Type Polymorphism' (TP) is a conceptual superset of 'Virtual Inheritance' (VI) in that TP functionality can be composed of child AND parent implementations while VI functionality is (by definition) the child implementation.

By having the critical distinction between VI and TP we can isolate issues/problems related to VI that can be solved with a TP design approach (the addition of supporting parent functionality to augment the child functionality).

This distinction between TP/VI also allows a more articulate definition of the 'virtual' control the parent can exhibit over the child's implementation in a purely VI context.

Note that 'Type Polymorphism' (TP) has such a rich history (see WikiPedia - Type Polymorphism) that Virtual Inheritance (VI) allows for the clear designation of 'virtual control'.

I think the definitions and suggestions discussed above should be put prior to any historcal/reference sections.

After the definition is vetted (and changes posted on main page) a terminology/conceptual history/reference section, similar to that found on the page for 'Type Polymorphism' should be started.

This would help to complete the definitive nature of the definition of Virtual Inheritance.

Finally I will write up and enter an initial definition of Implementation Inheritance to provide for the linkage (to it) defined above.

Following the history/reference I suggest a code sample for this page to the classic Figure/Circle/Square/triangle Virtual Inheritance (VI) example be put here.

If the classic Figure/Circle/Square/Triangle code sample exists else where the we should link to where it is and consider moving (the sample code) to this page as a definitive expression of (pure) virtual inheritance.

Shawnk

Polymorphic mechanism vs Control mechanism

In re-reading the Type Polymorphism page I note that Virtual Inheritance has both a polymorphic and control aspect.

The 'virtual control' aspect is the ability of a parent to call a 'virtual implementation' that is ultimately implemented in the child.

The 'polymorphic' aspect is the ability of the child implementation to 'type' the functionality (of its virtual method implementation) to the child's specific needs (for that functionality).

In articulating these two aspects the relationship of Virtual Inheritance to Type Polymorphism becomes clear. This explicit articulation (of the polymorphic/virtual aspects) will also help to strengthen the clarity of Virtual Inheritance from Multiple Inheritance (MI), Single Inheritance (SI), Implementation Inheritance (II) and Interfaces.

Shawnk

After re-reading the 'Language' section and researching older programming books and references I disagree with the 'solve .. problems' statement (see section on polymorphic/control).

It sounds as if the writer was a post java/C# world programmer with less that five years of coding in C++. Also sounds like the writer was not 'there' in the time frame (1989 - 1993) in the early days of C++ prior to its general use in industry software products.

I suggest the 'C++' section talks about syntax and implementation issues with virtual inheritance.

There was 'no problem' with virtual inheritance relative to ambiguity. Ambiguity is a phenomena that results from the implementation inheritance aspect of multiple inheritance.

Shawnk

The correct definition of Virtual Inheritance as been entered into the article. The point of dispute -

> The use of 'Virtual inheritance' as a synonym for 'Polymorphism' is incorrect.

.. has been articulated and a 'see also' section put with links to other concepts that are related to Virtual Inheritance.

Please review the full article and I will remove the disputed entry for this article.

Finally, if there are any more disputes, please be (1) very specific and (2) give alternate content to make your point (of dispute).

Should no disputes come up in week I will remove the disputed entry and put in external links to various references to correlate the current content of the article.

Shawnk

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

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)[reply]

"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:

#include <iostream>

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)[reply]

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)[reply]

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)[reply]