Is it correct to assume that diamond inheritance breaks encapsulation in C++?

Question

Look at the following code:

class Base
{
    int a;
public:
    Base(int b){a =b;}
};

class M1: public virtual Base{
public:

    M1(int a): Base(a+10){} // Expect a is increased by 10
};

class M2: public virtual Base{
public:

    M1(int a): Base(a+20){} // Expect a is increased by 20
};

class F: public M1, public M2{

public:
    F(int a): M1(a-2), M2(a-3), Base( a-10){} // ouch Base constructor called only once and with unexpected value!
};

Now while the code is really stupid, it highlights one problem, basically both classes M1 and M2 to working correctly assumes that Base is in a particular state (in this case it is increased by 10 or 20). Adding another derived class (F) breaks this encapsulation because Leaves "a" in a unexpected state because it decrease it by 10 instead of increasing.

M1 and M2 will access "a" with unexpected value then, to me this means that basically I breaked encapsulation, people is no longer free to change code in M1,M2 classes because it could eventually break F (also viceversa is true).

Actually what I'm asking for is the exact opposite of the

• Fragile Base Class problem

In the fragile base class problem we have "derived" class that is broke by base class changes, in my case it is the opposite:

• I have a derived class that is breaking one of the base classes.

Answer 1

A subobject doesn't own its virtual base. It potentially shares it with other subobjects of the same most derived object, which is the ultimate owner of all its virtual base class subobjects.

Saying that this breaks encapsulation is no more and no less correct than saying that e.g. std::shared_ptr breaks encapsulation. In both cases the state is shared between several users, not hidden, which is exactly the design objective of each feature.

In your case it would be simply wrong on the part of M1 to assume that the sate it gives to Base is the state that Base will eventually assume. It's merely a suggestion, taken into account only if there are no overriding circumstances. The most derived object ultimately decides how its virtual bases will be initialised. Any class with a stateful virtual base should be ready to handle this.