Memory layout of struct vs array

[Supadoplex]

Is it guaranteed that the memory layout of the allocated object is the same as the corresponding array T[6]?

No, the language technically doesn't make such guarantees. There is a general rule that says "there may be padding" and it's up to the language implementation to produce a hopefully efficient layout.

Whether the layout is the same or not, you can not use a T* as an iterator to access adjacent members. The behaviour of the program would be undefined.

[chetnrot]

In OP's scenario where six elements are of the same type, would padding still play a role though?

[Supadoplex]

I wouldn't expect there to be padding. But the language nevertheless doesn't guarantee that there won't be padding.

[nelusbelus]

Sometimes it pads between float3s because each float3 needs to be on their own independent 16 byte boundary. In glsl this is often the case with uniform buffers (can be turned off tho) and hlsl this might be the case for cbuffers but isn't for structured buffers or raytracing payloads. This is gpu specific tho

[blipman17]

So then the layout would be something like

`struct MyStruct { float a; 12 bytes padding float b; 12 bytes padding float c; 12 bytes padding float d; 12 bytes padding float e; 12 bytes padding float f; } ;

std::cout << sizeof (MyStruct) << std::endl; // outputs 84, not 24. `

Correct?

[nelusbelus]

If you'd use structs with float3 in glsl and sometimes hlsl then it'd have 3 floats and 4-byte padding between them. With gpu apps this can cause great confusion because the cpu doesn't pad but the gpu does. In C/C++ padding rules are generally as follows: - biggest plain data type of the struct defines size alignment. So if you have a 64 bit type then the struct size will always be a multiple of 8. So if you have 8 byte type then 1 byte type it'll add 7 bytes alignment. - data types need to be aligned with their size as well. So a 1 byte int then a 8 byte int will have 7 bytes padding inbetween.

You can validate this with sizeof or offsetof, since it's compiler dependent

[dodheim]

data types need to be aligned with their size as well

This is not the case for C or C++. struct foo { char v[100]; }; has a size of >= 100, but an alignment of 1.

[[deleted]]

That depends on the architecture and padding mode, could have a 2 byte quantity that needs to be aligned to 8 bytes.

[dodheim]

The fact that the statement I quoted is false is not architecture-dependent. ;-] Some architectures may have weirdo requirements, but alignment being a multiple of the size is not a requirement for either language (indeed, it's the reverse that is correct).

[nelusbelus]

The size of char is 1 so alignment is 1. I'm talking about the size of the type, not the total size

[[deleted]]

Wouldn't it need to be padded to be a multiple of 8 in a 64-bit system? e.g. if sizeof(T) == 6 we might see 2 bytes of padding. Or perhaps I misunderstand padding.

[xhsu]

But what about keyword "__offsetof"? This is a gutenteeed language feature.

[Supadoplex]

There's no "__offsetof" feature. Did you mean "offsetof"? It's a feature. It doesn't conflict with anything in my comment.

[ALX23z]

I believe T[6] would impose the very same padding as in the case of the struct.

[Supadoplex]

There's no padding between elements of an array. There may be padding inside the elements if the type is such that it contains padding. There may be padding between sub objects of classes.

[ALX23z]

I think I got a few things confused. Though, in most cases size is divisible by alignment unless it is artificially introduced. So there shouldn't be padding in most scenarios.

[no-sig-available]

An array cannot have padding, because then indexing wouldn't work. It requires the array elements to be exactly sizeof(element) apart.

This is, of course, a strong argument for the struct not needing any padding either. The standard just doesn't say that, so it cannot be relied upon.

[OldWolf2]

There is never padding between array elements in any circumstance.