CS 3370

 C++ allows multiple implementation inheritance  Handy for multiple “is-a” situations  Handy for reusing implementation without “is-a”  Leads to C++’s Darkest Corner (IMHO)  Inheritance “hierarchy” becomes a DAG  Ambiguities galore!  Complicated rules

 Invented with Common Lisp (“Flavors”)  Clients inherit implementation to gain a capability  Printable, Storable, etc.  Mixin classes are often abstract  Provides most but not all of feature  You override virtual function(s) to complete the feature  A Mixin that itself happens to derive from another class should do so via virtual inheritance (described later)  See AbleTest.cpp

 Suppose we have the proverbial Shape hierarchy  Circle, Triangle, etc.  If there is common code to all shapes, you can put it in Shape  If it is common to only some, keep it a secret  Don’t have it derive from Shape  See next slide…

class Shape {…}; class Common {…}; class Logo : public Shape {…}; class Circle : public Shape, protected Common {…}; class Triangle: public Shape, protected Common {…};

 A derived object has a subobject for each base class  data duplication!  Name clashes possible  Possible duplicate data via “diamond” inheritance  Examples: upcast.cpp, delta.cpp, ambiguous.cpp

 The derived class holds a pointer to the base subobject  It is not inherited by value  Only one subobject exists in the complete object  Therefore, there is no ambiguity in casting to the top-level class

 There must be no ambiguity in name lookup  If multiple base classes contain the same member names, you have a problem  If a member function, you can override it and do the Right Thing  If a data member, you must use “::”  And they must still be accessible  Examples: ambiguous2.cpp, disambiguate.cpp

 A fancy name for the way virtual functions work  The “most-derived” binding applies  B::f dominates A::f if A is a (direct or indirect) base class of B  Non-virtual functions work the same way for consistency

What if a D object calls f( ) via a pointer?

 How do you initialize a virtual base?  With diamond inheritance, there are multiple paths to the shared base  Which intermediate class is responsible?

 None!  There’s no criterion for choosing  It is always initialized, therefore, by the most derived class  Other initializations are ignored, but must be supplied by every derived concrete class  This makes for weird, but necessary code  See next slides

 All virtual bases are initialized before non- virtual bases  No matter where they are  In top-down-left-to-right order  Subobjects are never initialized twice  So the compiler has a lot of work to do to keep track of things

What is the order of initialization for G g; ? (See virtinit2.cpp)

 Affects copy constructors and assignment operators  Copy constructors work okay  Most-derived class must still take care of virtual base, similar to initialization example  Assignment operators are different!  They are not inherited  You must control all sub-assignments explicitly!  Examples: assignment.cpp, virtassign*.cpp