http://gcc.gnu.org/bugzilla/show_bug.cgi?id=53225
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |RESOLVED
Resolution| |INVALID
--- Comment #10 from Jonathan Wakely <redi at gcc dot gnu.org> 2012-05-04
19:44:31 UTC ---
(In reply to comment #9)
> As malloc() returns a void * there must be a cast to access the fields in the
> instance. We routinely use 'this_type' in our shop, which is defined to be
> the
> same as the class name. However, if you put the class name in, e.g. (A *)
> malloc(..) then you would definitely get the offset for an A, even after the
> method is inherited into a B.
Yes.
> The question comes down to, then, if when inheriting a method into a child, if
> the typedefs in the child apply or the typedefs in the parent apply. It should
Yes, that's the question, and the answer is they refer to the typedefs in the
base class, where the function is defined. There is no copying a base class'
member function into the derived class (that's not how inheritance works) and
no magical adjustment of members when you derive from a class.
In the A member function only names declared in A are visible.
> be the typedefs of the child, as offsets (type) is adjusted in inheritance. It
> would eliminate a lot of otherwise valid looking code otherwise.
Maybe valid looking, but it's not C++.
> This looks to be a general issue with multiple inheritance having nothing to
> do
> with operator new. Let me check that..
Please do, but it's nothing to do with multiple inheritance - the same thing
happens with single inheritance, typedefs in a base class' member function
always refer to the definition in the base class. With single inheritance you
might not notice your code is wrong, because A::count and B::count would be at
the same offset, but that doesn't change the fact the base class' member
function can only see names declared in the base class.
I'm closing this bug as invalid, the compiler behaves a required by the C++
standard.
> Though lets also keep in mind, the compiler makes no noise at all in this
> situation.
It can't really know what you're trying to do, so can't warn you that your
mental model of C++ is not how the language really works. The answer is not to
muck about with uninitialized memory when you aren't an expert in the language
and the object model.
