HP's object layout, clarification

[Christophe de Dinechin]

From: Jason Merrill <jason at cygnus.com>
>
> Your reasoning would also suggest that compilers can't have base and 
> derived classes at the same address, since they are not the "same  
object".
> When you're dealing with void*, the idea of what object a void pointer 
> points to is a bit vague.

First of all, I'm not a "Standard Guru", and I may be dead wrong on  
this. Which would be good news, because it would mean we have no bug  
:-)

However, I think you can legitimately claim that a pointer to a base  
and a pointer to a derived class, after conversion, point to the  
same object. The exact wording in [expr.eq] does not say that  
pointers compare equal if the objects they point to are the same, but  
that pointers can compare _after conversion_, and that then they  
compare equal if they point to the same object.

Casting a pointer to the derived or base class, when this is valid  
(unambiguous), indeed returns a pointer to the same subobject. The  
cast to (void *) in the examples given may have hidden this fact. We,  
internally, all read a cast to (void *) as meaning "the address  
corresponding to", which is why this cast was used in the first  
place.

There is also a note in [class.derived]/5, that reads:

	[ (...) A base class subobject may be of zero size
	(clause 9); however, two subobjects that
	have the same class type and that belong
	to the same most derived object must not
	be allocated at the same address (5.10). ]

which means that the address must not be the same, even if you would  
think that this would be unambiguous just because the size of the  
object is zero. I think this covers:

	struct A {};
	struct B: A {};
	struct C: A, B {};

The A in B and A in C subojbects must not be allocated at the same  
address, even though the zero size would make things like (A*)(C*)ptr  
unambiguous if they were allocated at the same address. This is only  
a note (non normative), so to me. To me, it just recalls a  
consequence of some other normative text, in that case, [expr.eq],  
which is explicitly referred to as the reason why you allocate these  
objects at the same address.

>
> I think it's pretty clear that the committee's intent was to allow  
empty
> bases to overlap except when they are of the same type.  Perhaps the 
> language in the standard could be clarified a bit.

My reading (but I may be wrong) is that empty base classes can  
overlap as long as they represent a single object, but that two  
subobjects in a given object that are not part of the same branch of  
a class hierarchy always need to be given a different address, even  
if they are zero size (and even if they have the same class.)

I have no personal preference on the subject, as long as everybody  
agrees on the correct solution. Do we want some clarification on this  
from c++core?


Regards
Christophe