I refer to the following as “multiple re-inheritance”:
- inheriting a class once directly and one or more times indirectly by inheriting one or more of its descendants
- inheriting a class indirectly two or more times by inheriting two or more of its descendants
I want to know if it exists and how to unambiguously access embedded subobjects.
1.) [Professional C++, 2nd ed.]† states a compilable program can't have a class that directly inherits both its immediate parent and said parent's parent class. Is it true?
Given a GrandParent
and Parent
, which extends GrandParent
, VC12 and g++ allows a GrandChild
to directly inherit from both Parent
and GrandParent
. In VC12 and g++, it’s possible to define these classes as follows:
GrandParent
declares an int num
data member. Parent
declares its own num
in addition to inheriting GrandParent
's num
. GrandChild
declares its own num
in addition to inheriting Parent
's and GrandParent
's num
s.
VC12 seems to allow unambiguous member access across the board, but g++ only allows it for some cases.
#include <iostream>
using std::cout;
using std::endl;
struct GrandParent { int num; };
struct Parent : GrandParent { int num; };
struct GrandChild : GrandParent, Parent { int num; };
int main()
{
GrandChild gc;
gc.num = 2;
gc.Parent::num = 1;
gc.Parent::GrandParent::num = 0; // g++ error: ‘GrandParent’ is an ambiguous base of ‘GrandChild’
gc.GrandParent::num = 5; // g++ error: ‘GrandParent’ is an ambiguous base of ‘GrandChild’
// --VC12 output; g++ output--
cout << gc.num << endl; // 2 ; 2
cout << gc.Parent::num << endl; // 1 ; 1
cout << gc.Parent::GrandParent::num << endl; // 0 ; N/A due to above error
cout << gc.GrandParent::num << endl; // 5 ; N/A due to above error
}
2.) Why is (a) gc.Parent::GrandParent::num
ambiguous in g++ when (b) gc.Parent::num
isn't? (a) uniquely describes its location on the inheritance tree. gc
only has 1 Parent
subobject, which only has 1 GrandParent
subobject, which only has 1 num
. For (b), gc
has one Parent
, which has its own num
but also a GrandParent
subobject with another num
.
3.) For gc.GrandParent::num
, it seems VC12 looks into gc
's immediate GrandParent
base subobject for the latter's num
. I’m guessing the reason it is unambiguous is that it’s a name lookup qualified by gc
, so the entity to the right of .
is looked for first in gc
's scope, and the most immediate GrandParent
to gc
's scope is the directly inherited one, not the indirectly inherited one via Parent
. Am I wrong?
4.) Why is gc.GrandParent::num
ambiguous to g++ when gc.Parent::num
isn't? If one is ambiguous, then shouldn't both be equally ambiguous? For the prior, gc
has two GrandParent
s; and for the latter, Parent
has 2 num
s.
†Gregoire, Marc R. et al. Professional C++, 2nd ed. Indianapolis, IN: Wiley Pubishing, 2011. p. 241. Print.
The common term for this is the diamond pattern (or diamond problem).
It is not an error per se, but as noted in the comments here, any attempt to access a direct base that is reduplicated elsewhere in the hierarchy will result in an ambiguity error.
One workaround would be to make the base indirect. The new inheriting constructors feature in C++11 allows perfect wrappers:
Given an unused tag type, this generates a new class derived from, and functionally identical to, the given base. The tag type may be an incomplete class denoted by an elaborated-type-specifier:
Now
GrandChild
can usemy_direct_grandparent::
to disambiguate member accesses.