size_t in a struct

[Shao Miller]

I guess a code generator could potentially accomplish something close
to this. I'd be interested in an algorithm which figures out the most
size-efficient ordering of the members, if anyone has one (or some
ideas for one).

Just sort the members into descending order of size.

I might be missing something... Suppose an 'int' has both size and
alignment of 4:

sizeof (struct {
char ca1[5]; /* 0 through 4 */
/* 3 bytes of padding; 5 through 7 */
int i; /* 8 through 11 */
/* No padding */
char ca2[3]; /* 12 through 14 */
/* 1 byte of padding; 15 */
}) == 16

The above is most likely, right? Whereas:

sizeof (struct {
int i; /* 0 through 3 */
/* No padding */
char ca1[5]; /* 4 through 8 */
/* No padding */
char ca2[3]; /* 9 through 11 */
/* No padding */
}) == 12

Right?

Yes. The advice has been shorted beyond usefulness. What I remember
being told (it was all fields round here, in those days) was to pack in
order of size (size being uses here as a proxy for alignment) treating
arrays as if they were just several fields of the array element type.

If it makes you feel better, I still hear "fields" in my head while
reading "members," on occasion.

Given your amendment to the previously advised strategy, can you think
of a situation where taking the result of that strategy and swapping the
first member out and injecting it as the last member could make a
difference for padding? For example:

struct foo {
int i;
char c;
/* Some padding, perhaps */
};

struct bar {
char c;
/* Some padding, perhaps */
int i;
};

 

[Shao Miller]

You mean to the total padding, presumably? No, I can't (well, excluding
rather contrived scenarios involving bit fields). Why do you ask?

I did mean to the total padding and total size, yes. I asked because I
couldn't think of any. I'm also wondering if ascending versus
descending makes any difference...

Given a type 't_8b' with size and alignment of 8, 't_4b' with size and
alignment of 4, 't_2b' with size and alignment of 2, if we have:

sizeof (struct foo {
/* 0 through 7 */
t_8b eight_byte;
/* 8 through 11 */
t_4b four_byte;
/* 12 through 13 */
t_2b two_byte;
/* 14 */
char c;
/* Padding: 15 */
}) == 16

doesn't it seem comparable, in size, to:

sizeof (struct foo {
/* 0 */
char c;
/* Padding: 1 */
/* 2 through 3 */
t_2b two_byte;
/* 4 through 7 */
t_4b four_byte;
/* 8 through 15 */
t_8b eight_byte;
}) == 16

? What's an easily accessible example for choosing descending versus
ascending? Is that strategy suggested in order to attempt to gather all
padding in one trailing lump?

 

[Phil Carmody]

The standard does not go into the specifics of padding.

It is a reasonably safe bet to assume sizeof(size_t) == sizeof(void*).

I have a compiler for which that's not true.
Remember x86 and segmentation?

Phil

 

[Ian Collins]

I have a compiler for which that's not true.

You would!

Remember x86 and segmentation?

Too well!

 

[David Thompson]

Or in order of alignment, which might not be the same thing.

On some architectures, there could be an advantage to putting
as many small members as possble at the beginning of the struct,
because smaller offsets can be faster.

Or the most-accessed members, as elsethread.

If C didn't require that struct members to follow their declared
order, the compiler could optimize the layout any way that makes
sense. It's too late to change that without breaking existing code,
but perhaps a future standard could add an attribute to specify
that the the compiler can alter the layout -- or it could be a
compiler-specific extension.

As an interesting contrast, Fortran has had structs -- which for
hysterical raisins it confusingly calls derived types -- standard
since F90, with the compiler allowed to reorder; F03 added standard
C-interop features (extensions for which were already common, but
different), and a C-interop derived-type can't be reordered.