http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
--- Comment #8 from Thomas W. Lynch <dimitrisdad at gmail dot com> 2012-05-04 18:57:40 UTC --- >No, that's not how it works. If Base::increment() writes to Base::field then it >is always at the same offset into the Base object. Whether that Base object is >a sub-object of another clas is irrelevant. I apologize, as I don't know how else to put it but in multiple inheritance that statement is just plain wrong. Fields move. You can see it in the debug output at the link, the field for 'count' moved by 4 bytes from what it was in the parent to where it is located in the child. I should note, also, that C++ uses name mangling to accomplish the effect of the type modifications I mentioned before. (I was a user of the original that made expanded macros into an intermediate directory ;-) So the manifest problem, if you could look at the macro output ;-) is probably an operator new mangled to be a child, but the internal type information still as a parent. The typedef for 'this_type' in the exmaple is simply a short hand that appears at the top of each of our templated classes so that there is a shorter name to use in the code. 'this_type' for class A is 'class A' for class B it is 'class B' etc. It does nothing. Look at the compiling example with the debug output there that shows the wrong offset, please don't quote the work arounds proposed as we are talking about the problematic case of course.
