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.