Talk:Virtual inheritance/Archive 2

This is an archive of past discussions about Virtual inheritance. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

Archive 2

Anon comment

This article is pathetic and is exactly the problem with these OOP pseudo-programmers who try to make a science out of technical definitions. Good job dragging out a simple concept to 5 pages of bull without even taking the effort to make a diagram. As a computer scientist, I frown upon you OO design pattern people who throw buzzwords left and right but have no concrete accomplishments other than writing endless amounts of OOP books which clutter barnes and noble. User:24.40.132.93

Actually I'm a Sr. developer who has signifcant industry experience doing everything from supercomputers at Intel to Artificial Intelligent engines for IBM. I've worked for HP, ATT as well as startups. The length is there to show (and prove) the intro text. I do software and projects for a living.

If people understand the intro section (still not in final form by the way) then there is no need to look further.

After training, teaching and helping college hires, etc. the WikiPedia source is meant to be self standing and that is the reason for code examples. The previous code examples did not compile and did not show much.

So, ... are you saying that Virtual Inheritance is not about Virtual Code elements contained in a Virtual control mechanism, or are you a 'virtual' key word kind of guy who states that virtual inheritance is anything with the 'virtual' keyword infront of it? I think the content and concepts is the issue here, nothing else matters.

Shawnk^talk—-Shawn wiki 11:37, 24 July 2006 (UTC)

You have a good point on the diagram issue. First I want to get this through dispute, concenses, citations and put in final references. After that I'd like a diagram myself but I'd like to get some input from others on that approach.

I also though about some tiny code examples in the intro/general section but links to examples are a cleaner approach to a stratified drill down solution.

Shawnk^talk—-Shawn wiki 13:26, 25 July 2006 (UTC)

I'm a big fan of patterns; it took work experience with large-scale projects after a CS degree for me to fully understand them, but they aren't just BS and they are useful. That said, I tend to agree regarding the rest this article. I don't follow it at all; I'm trying to help sort it out. —Ben FrantzDale 05:32, 24 July 2006 (UTC)

Ben - Rewrote the intro and general - The article is pretty much ready for review - The intro and general sections cover all the key concepts in virtual inheritance. All concepts are demonstrated in the code (They are not just BS - see the code). Let me know what parts of the article thesis are your biggest problems (just the top three). I assume that coming up with three top items is good place to see where your concern is centered.

Shawnk^talk—-Shawn wiki 17:06, 24 July 2006 (UTC)

More cleanup

I just re-added the cleanup tag. I am particularly dubious of the complete lack of citation and of the sheer length of the article. —Ben FrantzDale 05:52, 24 July 2006 (UTC)

Ben - I appreciate your efforts :-) But please hold off on the clean up tag for a few more days. I need do the final rewrite on a few sections. Thanks ahead of time for your patience and professionalism. In the mean time I do have some questions for you relative to the article.

[1] Do you have a problem with the language independence?

[2] Do you have a problem with the 'virtual code elements'?

[3] Do you maintain (in opposition to content) that anything with a virtual keyword is 'virtual inheritance'?

Thanks, again, for discussing the content.

PS - We can add the cleanup tag again later after discussing the content thesis and citations.

Shawnk^talk—-Shawn wiki 11:48, 24 July 2006 (UTC)

Introduction

Ben - Always intended to do a final rewrite on the intro and general sections because some of it links to

sections in the article. Could you look through the new intro and general section??

I'll look throught your comments below Tuesday or Wednesday if I can't get to them tonight.

Shawnk^talk—-Shawn wiki 17:02, 24 July 2006 (UTC)

I've said above that I can't follow the introduction. Let me pick that apart.

Virtual inheritance is a form of inheritance in object-oriented programming languages.

I agree.

It allows a parent to control code elements implemented in the children which inherit from it.

I've never seen the phrase "to control code elements" outside of this article. Alone this sentence sounds like a description of virtual functions.

--------shawnk response to Ben----------

Read these sections:

The control concept

The code

From the section - Control Mechanism Vs. Polymorphic Mechanism

The word 'control' means the code element may be callable (an abstract method),

assignable (a primitive data type) or both (an event). Whatever the

relationship (callable, assignable, etc) the parent 'controls' a 'virtual' code

element.

From the section - Use Context of Virtual Code Elements in C#

public

void Main_process()

{

Observer target_1 = new Observer("Number One");

Observer target_2 = new Observer("Number Two");

//

m_subject_ref.notification_targets += target_1.Notify_me; // Loadable virtual code element

m_subject_ref.notification_targets += target_2.Notify_me;

//

m_subject_ref.Notification_gate_flag = true; // Assignable virtual code element

m_subject_ref.Fire_event( "Event_1" );

m_subject_ref.Notification_gate_flag = false;

m_subject_ref.Fire_event( "Event_2" );

m_subject_ref.Notification_gate_flag = true;

m_subject_ref.Fire_event( "Event_3" );

}

From the section - Use Context of Virtual Code Elements in C#

Assignable State Space : In the example above the Main_process of the Observer_manager contains

the Notification_gate_flag code element which is an assignable code element (single value

assignment). The notification_targets code element is a loadable code element (multi-value

assignment).

In Virtual Inheritance code elements are said to be 'controllable'. This means that a code element can be called

(method), assigned (bool) or loaded (event). The conceptual semantics of the control aspect do not, and

should not, address the implementation details of a particular compiler or language. This control aspect is an

important difference between virtual inheritance and virtual functions (VTables - compiler implementation).

Shawnk^talk—-Shawn wiki 12:34, 25 July 2006 (UTC)

-------shawnk response to Ben----------

Ben - Forgot to include the binding aspect - Also see:

language binding

From the section - Code Element Binding and Coupling

At the language level a code element may be called (method), assigned (primitive data type - single value

assignment) or loaded (event - multiple value assignment). At the binary level various 'under the cover'

operations are performed that connect the virtual code elements to their targets, sources and destinations.

Binary bindings are processor, operating system, and compiler dependent and are not addressed at the

language independent level used herein.

Thus the two aspects of binding (call, assignment, load, etc) and coupling (tight/loose) have important

implications on the use context of the virtual code element. Therefore virtual code element binding and

coupling, at the language level, are fundamental aspects of Virtual Inheritance (VI).

Shawnk^talk—-Shawn wiki 14:17, 25 July 2006 (UTC)

By using Virtual Inheritance any polymorphic functionality, within the parent, is moved into the children (functional dispersion), and then controlled (by the parent) along the lines of inheritance between parent and child (ancestor/descendent).

I don't understand. I haven't heard the term "functional dispersion" elsewhere. Also, wouldn't static polymorphism count as "any polymorphic functionality" even though it isn't "virtual"?

-------shawnk response to Ben----------

Removed this so we could get to a intro we agree on.

On the static polymorphism - any form of polymorph is centric first to polymorphed units and second to some connection (bind, coupling) mechanism like inheritance, event binding, etc. So, even though I removed this paragraph you have a good point. In the new intro I tryed to put in a simple as possible factual statement that would get all readers familiar with VI on the same page - something we could all agree on.

So the intro is an aggrement page entailing and introducing the main thesis of the article. I tried to strip everything from the new intro that was detailed about VI. All the keywords and links are in the general section.

Shawnk^talk—-Shawn wiki 12:17, 25 July 2006 (UTC)

This is a 'language independent' definition not constrained by syntax mechanisms in specific computer languages like Eiffel, C++, C#, and Java. The term General Virtual Inheritance (GVI) should be used to qualify the language independent meaning relative to any alternate language specific meaning.

Can you cite a source for "general virtual inheritance"? The Google hits I see are to this page. I agree that the language-independent menaing may be dealt with separately.

-------shawnk response to Ben---------

Removed paragraph - GVI keyword is now in general section - There is no reference for the term general virtual inheritance. The phrase, in the article, describes a 'virtual code element with a parent use context'. Do you have a another term to replace 'virtual code element with a parent use context' that can be abreiviated (GVI) for tagging to make the article readable. We can discuss this in a new section on key words used in the article if you like. Just list the keywords you have concerns with and state concern as (1) concept or (2) phrasing or both and we can 'pound them out together' :-)

Shawnk^talk—-Shawn wiki 12:59, 25 July 2006 (UTC)

Unless qualified otherwise Virtual Inheritance (GVI) refers to the language independent meaning. Resolution Inheritance (RI) is the language independent meaning referring to state space collision resolution in the context of Multiple Implementation Inheritance (MII) of state.

Should this paragraph be preceeded by "Within the context of this article"? Also, "Resolution Inheritance" has its first Google hits on this page as well. I am dubious.

-------shawnk response to Ben----------

The 'within context of article' (a temporary line) has been removed along

with the paragraph. All the key words describe VI in the code examples.

The start of the C++ section discusses the resolution inheritance phrase.

Go ahead and do a search/replace on a PDF version and read whatever you

propose.

I wanted to do a quality article that focused on just the code and

virtual inheritance. I did not want another shallow, shoddy and regurgitated

example of so much of the junk on the Internet. I'll open a section on

this in the discussion this week.

I especially designed a stratified article that allows one to go as deep as

needed with some real code examples, not some worthless syntax example

that had no content relevant to the phenomena.

Lets pound out the intro on this one and then move on the general section.

Thanks again, Ben, for your work on this. I am sure that after we review

the (1) code/phenomena, (2) phrasing and (3) article partitioning/stratification

we can cover the (4) citations and references. The citations I have do

cover the phenomena but may use different phrasing. Again, try a substitute

and replace. I want to see what others come up with to harden out a good

solution to the concerns you mention.

Shawnk^talk—-Shawn wiki 12:59, 25 July 2006 (UTC)

Also see the Semantics section which addresses the conceptual scope of Virtual Inheritance syntax mechanisms.

I'm dubious of this level of self-reference, especially in an article without citations. I tend think that the article is too long if users must be directed to specific portions of it. —Ben FrantzDale 12:57, 24 July 2006 (UTC)

Ben - The first majority of links are drill down or navigation links. This allows a quick descent to the code examples for the phenomena mentioned at the higher layers of the text. The second majority of links are to relevant WikiPedia articles on related material.

Shawnk^talk—-Shawn wiki 05:27, 27 July 2006 (UTC)

Ben - Appreciate your input as always. You are more than welcome to re-write the article after I'm done with it. I am more concerned about accuracy of phenomena than terms. I'm re-writing the intro and general sections as we speak (have not ready through your input above but look forward to doing so). I did note in a breif look at the above about sefl-reference. Much of the terms I am using are 'baggage free' that SHOULD not show up anywhere but explain EXACTLY what the code does. I look forward to your replacing them with some 'baggage free' terms that will work and not change the meaning about what happens in the code.

If you are glutton for punishment :-) you can do a rewrite but if you start to remove key concepts that are there specifically to resolve controversy then we come to the point of the article.

Two camps exist - Virtual keyword or Virtual phenomena (this is simplification)? Language independence or just C++? Do these things exist (VCM, use context) and if so what do we call them? After the intro/general rewrite we (the WikiPedia community) should be ready to really rip the article apart. My attitude is really matter of fact bcause I want to see the controversy addressed and solved. This is what WikiPedia is all about. Merciless editing of content :-)

Will look over your input above in detail as soon as I update the intro/general. Will respond more fully then.

Thanks again for your professionalism :-)

Shawnk^talk—-Shawn wiki 13:21, 25 July 2006 (UTC)

WikiPedia C++ project status

This article is an article about virtual inheritance in object-oriented languages.

The author (me) did not put this 'C++' project tag here.

I trust, Ben, that when you put that tag in here you are not trying to force the article to be only a C++ article but, rather, the C++ section should be reviewed by the WikiPedia C++ community (an excellent idea :-)

Please confirm that above is the correct meaning of the 'tag' for the C++ project.

By the way: I Love C++. It is my preferred language because of MII. I love C# as well but hope for a language in the future that will combine the best of both languages :-)

Shawnk^talk—-Shawn wiki 13:21, 25 July 2006 (UTC)

Virtual Inheritance article ready for your review

Ben, haven't heard from you to discuss the code/core phenomena.

Also some of the other disputants have not replied or answered in this discussion. I take that to mean they are satisfied with any current imperfections in the article and will let it ride.

As always I look forward to any critique to improve the article.

Went ahead and put in the reference list and quotations.

Article is ready for final review and dispute (except for one diagram to put in fall 2006 - see below).

Please review when you get time.

All code and phenomena is intact. Researchers should not have to go anywhere else but can copy and paste from the article on any aspect of Virtual Inheritance (hopefully).

The drill down stratified approach should allow most to review the intro and not go further if they are already familiar with the subject.

At the same time high school aged programmers should also be able to drill down and navigate quickly to understand the core concepts.

Anon had a good recommendation on a chart or diagram which I would like to do but I want the current article to ride for a few weeks or months before doing so.

I expect that when the college fall session starts we should get more traffic and comment on the article. (Summer is always lazy and laid back :-)

Please review the next-to-final version (will add a good diagram this fall) of this article when you get time (end of July 2006).

I still have some other WikiPedia articles to finish before I get back to the diagram for this article.

Have about 10 times more references and quotes than in the article but to minimize article (and still keep a self standing reference quality) I only put in the basic stuff.

I hope I have answered your questions and concerns on links, references, etc.

I have done a pretty good research search on alternate terminology AND historical terminology (none of which is in the article) in the worlds best research knowledge bases, services. Hopefully you can replicate this at your college.

See the article keyword list at the top of the article.

Please try to do a substitute and replace prior to recommending any alternate terms. Please also site referential history and citations of prior use. My history goes back to inception point (see quotations) and many other key articles from the 1960s time period.

Be especially articulate on alternate terms as to WHY you think they are better (especially citations and standard industry use).

Because of Blogs, personal opinion (forums) and quickie articles over 99 % of Google searches are either inaccurate or not usable (when compared to research databases, services, etc) in patent level work.

To the best of my understanding the article is now up to that standard level (all style issues aside).

Please let me know what you find in your research.

shawnk - author

Shawnk^talk—-Shawn wiki 17:01, 28 July 2006 (UTC)

Article Hard to Follow

Response by user (author)

Shawnk^talk—-Shawn wiki 15:18, 30 July 2006 (UTC)

to user:

—Ben FrantzDale

Ben, your comment '...I don't follow it at all..' (see above in this discussion) concerns me as I thought the article was pretty clear on 'virtual code elements' and 'use context'. Also I felt that 'implementation code elements' is a pretty good contrast to show the virtual/implementation concepts so fundamental to Object-Oriented Programming (OOP).

In my concern, and to ensure others could 'follow' the article I put in the quotation section to relieve other readers of replicating some of the research to the article.

The last line of the article is key and centric to 'virtual code elements'. These quotations are from the programmers who developed the object-oriented language paradigm.

I think if you just go to the last line (of the article) and read it several times you could 'follow' the main thesis of the article (virtual inheritance). If you still have a problem following the article you may try to read all of the quotes and 'connect the dots' (so to speak) for the (Eureka statement)

'...foundation for a completely new language approach..'

If the article is still 'hard to follow' I added the 'External Links section' with a link to the ACM site. This should make it easier for you (and others) to validate the content and thesis. If you are a member (of ACM) you should be able to research the paper (online) and review the context of the quotations.

The reference;

[5] Nygaard, Dahl, (Wexelblat) : History of programming languages, Academic Press 1981

is considered by many to be the definitive paper on the history of the object-oriented programming paradigm.

The 'eureka' statement (see quotations section) is a good place to start (in the paper) to see how virtual inheritance (as defined in this article) was a key concept right from the inception point of OOP.

Also the reference;

[03] Martin, Odell - 1993 : Object Orientation

is indicative of the mid 1980s OOP maturity in which many (of these publications) have a succinct definition of virtual inheritance which agrees (rightly so) with the founding concepts in reference [5].

If you still have a problem following the article you may wish to review reference [3] and reference [6].

Even after all of this, if the article is still 'hard to follow' and you want to '..help sort it out..' please let me know of your recommendations :-)

Your input has been very helpful in making the article better for others who may find virtual inheritance (as described in this article) 'hard to follow'. Although the current article has imperfections I trust they do not detract significantly from the article thesis and, currently, it is 'easier to follow' now that the article is in the 'next to final form'.

As mentioned elsewhere (in this discussion) I will try and do a good, simple diagram from one of the code examples but I need to complete some other WikiPedia articles first.

Hopefully, after the diagram, the article will be understandable and 'easy to follow' for even high school level students, so important to the continuation of our industry.

I always look forward to your professionalism and help. Thank you again for your input.

Shawnk^talk—-Shawn wiki 15:18, 30 July 2006 (UTC)

Missing eat() overrides in example

Shouldn't the coding example have overrides of eat() in the derived classes to be correct (and clear)? - Dougher (talk) 17:39, 18 January 2008 (UTC)

Not really. The eat() method could make use of private variables (as an example). This would show that the bat.WingedAnimal::Animal::eat() and bat.Mammal::Animal::eat() end up acting on different Animal objects. The non-virtual inheritance will create two Animal objects. With virtual inheritance, there is only one Animal object. This is as conceptually important as the name resolution problem; which helps mislead the naive reader to think that virtual methods and virtual inheritance are related. I think they should be thought of as different concepts. However the naming helps create this confusion. Also, the 'vtable distance' seems weird to me, but I don't have Inside the C++ Object model handy to check this. 69.77.161.3 (talk) 16:25, 23 October 2008 (UTC)

Actually the article does note the double Animal instances, but it is in later sections. I think it would be clearer earlier in the article. The use of vtable can also confuse people as this is usually associated with virtual methods; not that the information is incorrect, just easy to be mis-read. 69.77.161.3 (talk) 16:30, 23 October 2008 (UTC)

Mystery sentence, please help

"It is used when inheritance is representing restrictions of a set rather than composition of parts."

Excuse my ignorance, but what does this mean? I'm conversant in OO and C++, but "restrictions of a set" is not very evocative, and "composition of parts" could suggest private inheritance, although composition to my mind is synonym of aggregation (has-a), not inheritance. Thank you. 118.7.198.171 (talk) 02:14, 14 June 2009 (UTC)

Broken example

Hi there, I tried to compile/link the "The problem" example.

class Animal 
{
 public:
  virtual void eat();
};
 
class Mammal : public Animal 
{
 public:
  virtual int getHairColor(); // Minor complaint, Color is not defined. I suggest changing to getNumberOfNipples() or something
};
 
class WingedAnimal : public Animal 
{
 public:
  virtual void flap();
};
 
// A bat is a winged mammal
class Bat : public Mammal, public WingedAnimal {};

I report the errors I got (with g++ 4.3.0 20080305) from each of the following mains

int main()
{
	Bat bat;
	bat.eat();
}

multiple inh.cpp: In function 'int main()':
multiple inh.cpp:27: error: request for member 'eat' is ambiguous
multiple inh.cpp:6: error: candidates are: virtual void Animal::eat()
multiple inh.cpp:6: error:                 virtual void Animal::eat()

So far, so expected. However, the suggested disambiguation syntax also fails:

int main()
{
	Bat bat;
	bat.WingedAnimal::Animal::eat();
}

multiple inh.cpp: In function 'int main()':
multiple inh.cpp:27: error: 'Animal' is an ambiguous base of 'Bat'

...as does a similar syntax, from Meyers, that the compiler likes, but the linker rejects:

int main()
{
	Bat bat;
	bat.WingedAnimal::eat();
}

/cygdrive/ccR850Oh.o:multiple inh.cpp:(.text+0xa1): undefined reference to `Animal::eat()'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.text$_ZN6AnimalC2Ev[Animal::Animal()]+0x8): undefined reference to `vtable for Animal'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.text$_ZN6MammalC2Ev[Mammal::Mammal()]+0x16): undefined reference to `vtable for Mammal'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.text$_ZN12WingedAnimalC2Ev[WingedAnimal::WingedAnimal()]+0x16): undefined reference to `vtable for WingedAnimal'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTV3Bat[vtable for Bat]+0x8): undefined reference to `Animal::eat()'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTV3Bat[vtable for Bat]+0xc): undefined reference to `Mammal::getHairColor()'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTV3Bat[vtable for Bat]+0x18): undefined reference to `Animal::eat()'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTV3Bat[vtable for Bat]+0x1c): undefined reference to `WingedAnimal::flap()'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTI3Bat[typeinfo for Bat]+0x10): undefined reference to `typeinfo for Mammal'
/cygdrive/ccR850Oh.o:multiple inh.cpp:(.rdata$_ZTI3Bat[typeinfo for Bat]+0x18): undefined reference to `typeinfo for WingedAnimal'
collect2: ld returned 1 exit status

Please help. Thank you. 118.7.198.171 (talk) 02:53, 14 June 2009 (UTC)

Silly me, should have read the error message more closely. The problem is that the linker cannot find the definitions (duh!). Still, the suggested syntax for disambiguating is still not compiling, so I have changed it in the article. 118.7.198.171 (talk) 03:07, 14 June 2009 (UTC)

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)

Clean up suggestion

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

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