Re: Computer architects leaving Intel...

On 16/09/2024 09:18, BGB wrote:

On 9/15/2024 12:46 PM, Anton Ertl wrote:

Michael S <already5chosen@yahoo.com> writes:

Padding is another thing that should be Implementation Defined.

>
It is.  It's defined in the ABI, so when the compiler documents to
follow some ABI, you automatically get that ABI's structure layout.
And if a compiler does not follow an ABI, it is practically useless.
>

 Though, there also isn't a whole lot of freedom of choice here regarding layout.
 If member ordering or padding differs from typical expectations, then any code which serializes structures to files is liable to break, and this practice isn't particularly uncommon.
 

Your expectations here should match up with the ABI - otherwise things are going to go wrong pretty quickly.  But I think most ABIs will have fairly sensible choices for padding and alignments.

Say, typical pattern:
Members are organized in the same order they appear in the source code;

That is required by the C standards.  (A compiler can re-arrange the order if that does not affect any observable behaviour.  gcc used to have an optimisation option that allowed it to re-arrange struct ordering when it was safe to do so, but it was removed as it was rarely used and a serious PITA to support with LTO.)

If the current position is not a multiple of the member's alignment, it is padded to an offset that is a multiple of the member's alignment;

That is a requirement in the C standards.
The only implementation-defined option is whether or not there is /extra/ padding - and I have never seen that in practice.  (And there are more implementation-defined options for bit-fields.)

For primitive types, the alignment is equal to the size, which is also a power of 2;

That is the norm, up to the maximum appropriate alignment for the architecture.  A 16-bit cpu has nothing to gain by making 32-bit types 32-bit aligned.

If needed, the total size of the struct is padded to a multiple of the largest alignment of the struct members.

That is required by the C standards.

   For C++ classes, it is more chaotic (and more compiler dependent), but:

Not really, no.  Apart from a few hidden bits such as pointers to handle virtual methods and virtual inheritance, the data fields are ordered, padded and aligned just like in C structs.  And these hidden pointers follow the same rules as any other pointer.
The only other special bit is empty base class optimisation, and that's pretty simple too.