Liste des Groupes | Revenir à c arch |
On 16/09/2024 09:18, BGB wrote:Yeah. It is "almost fixed", as there are a lot of programs that are liable to break if these assumptions differ.On 9/15/2024 12:46 PM, Anton Ertl wrote: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.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.
>
OK.Say, typical pattern: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.)
Members are organized in the same order they appear in the source code;
Extra padding seems like it wouldn't have much benefit.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.)
This comes up as an issue in some Windows file formats, where one can't just naively use a struct with 32-bit fields because some 32-bit members only have 16-bit alignment.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.
For simple cases, they may match up, like a POD class may look just like an equivalent struct, or single-inheritance classes with virtual methods like a struct with a vtable, etc... But in more complex cases there may be compiler differences (along with differences in things like name mangling, etc).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.
>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.
>
>
For C++ classes, it is more chaotic (and more compiler dependent), but:
The only other special bit is empty base class optimisation, and that's pretty simple too.
Les messages affichés proviennent d'usenet.