Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!decwrl!sun!pitstop!sundc!seismo!uunet!mcvax!philmds!leo
From: leo@philmds.UUCP (Leo de Wit)
Newsgroups: comp.lang.c
Subject: Re: Optimal structure field ordering
Message-ID: <531@philmds.UUCP>
Date: 27 Jun 88 08:27:14 GMT
References: <163@navtech.uucp> <806@garth.UUCP>
Reply-To: leo@philmds.UUCP (L.J.M. de Wit)
Organization: Philips I&E DTS Eindhoven
Lines: 28

In article <806@garth.UUCP> smryan@garth.UUCP (Steven Ryan) writes:
>In article <163@navtech.uucp> mark@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.