[swift-dev] SILNode versus C++

[Jonathan Prescott]

This is expected.  The inheritance chain ultimately ends up a B in both cases, so the reference to j is ambiguous, and the compiler can’t resolve which B is meant.

This works.

class B
{
	protected:
		int i;
		union { int j; };
};

class C 
{
	protected:
		int i;
		union { int j; };
};

class X : public B { };
class Y : public C { };

class Z : public X, public Y
{
	int a() { return X::i; }
	int b() { return Y::i; }
	int c()	{ return X::j; }
	int d()	{ return Y::j; }
};

If “B” is a metaphor for a common base class in the “real” case, you are going to run into one of the pitfalls of C++ multiple inheritance, the “diamond” inheritance problem (Z inherits from X and Y, which both inherit from B, forms an inheritance “diamond” if you graph it out). That is why C++ has virtual inheritance.  However, with anonymous unions, there is still an ambiguity as to which union member to access (as far as clang++ is concerned).  Giving it a name or encasing it in another class instance resolves that ambigiuity.

Jonathan

> On Dec 16, 2017, at 9:08 AM, David Zarzycki via swift-dev <swift-dev at swift.org> wrote:
> 
> Hello,
> 
> I’m trying to improve SILNode memory layout density by adopting the AST bitfield macros. Unfortunately, multiple inheritance doesn’t seem to get along with anonymous/unnamed unions. Here is a distillation of the problem:
> 
> class B {
> protected:
>    int i;
>    union { int j; };
> };
> 
> class X : public B { };
> class Y : public B { };
> 
> class Z : public X, public Y {
>    int a() { return X::i; } // works
>    int b() { return X::j; } // fails
> };
> 
> Is this expected C++ behavior? I can certainly workaround this by naming the unnamed union, but before I do, I thought that I should check here first.
> 
> Thanks,
> Dave
> _______________________________________________
> swift-dev mailing list
> swift-dev at swift.org
> https://lists.swift.org/mailman/listinfo/swift-dev