This is great for the general programmer (someone who is not knowledgeable or caring about details like this.)
Unfortunately, this blows for people who do (someone like me.)
This is great for the general programmer (someone who is not knowledgeable or caring about details like this.)
Unfortunately, this blows for people who do (someone like me.)
One can opt-in to a fixed in-order layout with `#[repr(C)]` and even avoid padding for such a struct with `#[repr(C, packed)]`.
NB. in general it is impossible to pack a struct perfectly manually, e.g. generic structs can have their order for minimal size change depending on what types they're used with. It can even be somewhat platform specific, with e.g. pointers changing size/alignment on 32-bit vs. 64-bit computers (although pointers probably aren't problematic, since they're switching between two adjacent classes).
Or is it doing it suboptimally? (Say you want two fields in the same cache line, but the compiler sorts them away.)
In the end, however, my reservations are mostly due to a "get off my lawn" mentality.
Only when the difference in performance is end-user discernible. I do make sure the code is well crafted in those bounds though. There's no _valid_ excuse for crafting ugly code.
Coincidently my stuffed toy that I have kept throughout my childhood was named "Mel the Pal." I just noticed the irony of that. :)