Understanding Virtual Inheritance Memory Layouts
I'm working to better understand the solvable memory schemes that vTables and vPointers give us. I fully understand polymorphism and why it works, and I really have no problems with it, however there are a couple of small things that I seem to be inclined to regarding memory layouts and understanding of virtual base offsets . I know that these things are not absolutely necessary in everyday C ++ code, however I am interested to know what is going on.
I turned to this site for help in understanding the memory structure resulting from using virtual inheritance.
In the Virtual Page Inheritance section, about halfway down, it offers visual effects for the generated virtual tables, however I want to clarify the order in which, in my opinion, several events occur:

(source: phpcompiler.org )
In the figure above it seems to me that:
- First we enable vPtr, which points to the
Left table - Then include first any values ββunique to the
Left class ( Left::b ) - The offsets are then computed, so we can put any actually inherited data directly after the data we just included. The size is vPtr +
int Left::b = 8, so we shift Top::a by 8 and add this to the end of our layout. - Rinse and repeat the correct class.

(source: phpcompiler.org )
In this picture above it seems to me that:
- First we enable vPtr of the first class, which we inherit from
- Since we actually do not inherit from this immediate base class, we can directly inherit any non-virtual data members specific to this class without offsets, i.e. (
Left::b ) - We enable vPtr of the second class, which we inherit from
- Since we actually do not inherit from this immediate base class, we can directly inherit any non-virtual data members specific to this class without offsets, i.e. (
Right::c ) - Then include any unique data in the
Bottom class, Bottom::d - Then we calculate the offsets for the virtual data in our superclass and include them at the end of our memory layout.
- Finally, we are done with our memory layout for the
Bottom class
It seems to me that the processes described above make sense in determining the structure of memory in many cases, but I wonder what will happen if I change something.
- How will the memory structure change if
Bottom actually inherited from Left and Right - The lower part inherits
Left and Right regularly, but, say, Right defines its own int a , obviously, this would make bottom.a equal to what bottom.Right::a , since its last redefinition, however where it should be placed in the memory layout?
I have a proposal plan for each of my questions (2), and I would like to know if my thoughts are correct behind them, and if not, why ... Thank you!
1.)
+--Bottom---+ | vPtrLeft | | vPtrRight | | Bottom::d | | Left::b--+---From offset calculated by vPtr.Left in Bottom vTable | Right::b-+---From offset calculated by vPtr.Right in Bottom vTable | Top::a --+---From offsets calculated from vPtr.Left and vPtr.Right +-----------+
- Turn on vPtr.Left, then find any unique data on the left that isnβt virtually inherited (
None ) (i.e. don't require offsets) - Turn on vPtr.Right, then look for any unique data that Right doesn't inherit virtually (
None ) (i.e. don't require offsets) - Add any data specific to this class, (
Bottom::d ) - Get all the virtual data that needs to be offset from
Left , then Right , climbing the chain of inheritance, until we finish Left and Right virtual inherited attribute Top::a
2.)
+---Bottom---+ | vPtrLeft | | Left::b---+---inheriting normally from Left | vPtrRight + | Right::c--+---inheriting normally from Right | Right::a--+---inheriting normally from Right | Bottom::d | also most recently overrided value for A | Top::a----+---From offsets calculated from vPtr.Left and vPtr.Right +------------+
Thanks for the feedback on the logic of these layouts.
Edit:
I know this was marked as duplicate, but I think this question is more specific than the other, and I'm looking for some answers to the usual multiple virtual inheritance options in order to understand the memory schemes of objects with virtual inheritance