TITLE: alignment requirements of classes

(source: comp.std.c++)

[ This picks up on a discussion about the memory alignment
  requirements of classes. -adc ]

RESPONS: clamage@Eng.sun.com (Steve Clamage)

[edited]

I assume you mean a class like
	class Short { short val; };
with non-virtual member functions added. You can't assume the size and
alignment of the class will be the same as its only data member, and no,
the standard provides no special support for this special case.


RESPONSE: abell@mindspring.com (Andrew Bell)

Seems like if you only have one data member and no virtual functions,
there's no reason to arbitrarily restrict it to a greater alignment
level, save maybe to make compiler programmer's lives (and maybe
debugger programmer's lives) trivially easier. 


RESPONSE: clamage@Eng.Sun.COM (Steve Clamage), 27 Mar 96

That isn't the reason. C++ implementations don't exist in a vacuum. They
have to coexist with platform ABIs (Application Binary Interface, the
bit-level description of data and function calls). It is common for an ABI
to specify rules for structured types that are different from the rules
for simple types, no matter what the contents of the structure. That is,
all structured types are treated by one set of rules.

If a platform ABI required that all structs be at least 4-byte aligned and
padded to 4-byte boundaries, but C++ required that struct alignment and
padding be no stricter than that of the strictest member, you place the C++
implementor in an impossible position. Either the generated code is
incompatible with system and 3rd-party libraries, or the compiler violates
the C++ standard.

Nothing prevents an implementation from implementing class Short above in
the same way as type short if the ABI allows it, but the point is that you
can't depend on type Short being either the same as or different from
type short.

Clamage:

The typeids of two types compare equal if and only if they are
the same type. Base and derived classes are not ever the same type.

Bell:

Fair enough, although in this case RTTI forces the creation of an
additional vtable that wouldn't normally be necessary.  Since the
general criterion for RTTI support in a class in the first place is
the existence of any virtual functions (and thus a vtable), it doesn't
seem like it would be too unreasonable to make classes with identical
vtables evaluate to the same thing.  Adding an operator to a class
(externally) doesn't change its identity; should a non-virtual member
function do so?

Clamage:

That's a philosophical question about what is a type. C++ follows the
common convention that different types are different types. The One-
Definition Rule says that there is only one definition of a type in
a program. In addition, the type must be defined in a single declaration,
not spread out. Some consequences of this consistent set of rules are that
a derived type is always a different type from the base, and namespace-scope
functions are not part of any class's type.

Certainly different rules are possible, and other languages have other
rules. The C++ rules are easy to understand and the consequences are
easy to predict. Not so if type equivalence depends on subtle distinctions.