This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/53225] static operator new in multiple inheritance carries incorrect type information for the class


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]