Optimal structure field ordering

[Leo de Wit]

In article <806 at garth.UUCP> smryan at garth.UUCP (Steven Ryan) writes:
>In article <163 at navtech.uucp> mark at navtech.uucp (Mark Stevans) writes:
>>                                        The easy way to save space on almost
>>all C implementations is to sort your structure fields in order of descending
>>size of the field type.
>
>(Not being a C expert, I don't know if this true.)  A nice language definition
>will say you can define fields but doesn't say what order they are allocated. It
>would be better if the compiler can sort the fields to optimise access and
>balance space/time. In this way you can write the structures as it makes sense
>and not worry about dinking it for a particular machine.

K&R, page 196, section 8.5, Structure and union declarations:

Within a structure, the objects declared have addresses which increase
as their declarations are read left-to-right. Each non-field member of
a structure begins on a addressing boundary appropriate to its type;
therefore, there may be unnamed holes in a structure.

which explains everything, and frustrates any hope on optimization
(only the left-to-right puzzles me, most program text being written
top-to-bottom; B.T.W. what do Chinese program texts look like ? 8-).

As far as the field size is conceirned, this is compiler/O.S.
dependent, as Steven pointed out; so this may be not portable. 
B.T.W. lets call it member size; a field in K&R denotes a bit field.

     Leo.