Re: g++ 2.95.2 calculates wrong size for class

["Martin v. Loewis" <martin at loewis dot home dot cs dot tu-berlin dot de>]

> Virtual methods I understand why not (vtable for virtual methods), also
> virtual bases would be out. But I don't understand why not access
> declarations, or bases (sure, can get hairy to grasp the exact layout, but
> it should be like a struct with another inside, isn't it?)

I was talking from a standards point of view here. Layout is
guaranteed for POD structures. These are aggregates (8.5.1), i.e. they
must not have user-declared constructors, private or protected
non-static data members, base classes, or virtual functions. In
addition (9/4), they must not have pointer-to-member members,
reference members, or (recursively) non-POD members, and no
user-defined copy-assignment, and no user-defined constructor.

The restriction on on access-specifiers (which I actually meant) is
because the standard permits re-ordering of fields if they are
separated by an access-specifier. g++ makes no use of this permission;
neither does the new ABI. I don't know why the standard permits
re-ordering, but portable code must consider that a compiler may
reorder fields.

Likewise, representation of base classes may vary widely. In the
current g++ ABI, virtual base classes are layed-out via a pointer
indirection, meaning that the order of fields of the base class
relativ to the object start may vary. In the new ABI, the virtual
table pointer is always at the start of the object, even if the base
object has no virtual table. So assuming that the base object is
always at the beginning is incorrect. In the new ABI, empty bases and
nearly empty bases are normally removed from the complete object, so
assuming anything about even the size of a base object is
non-portable.

Regards,
Martin