Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pacbell!att!ihnp4!ihlpf!nevin1
From: nevin1@ihlpf.ATT.COM (00704a-Liber)
Newsgroups: comp.lang.c
Subject: Re: Optimal structure field ordering
Message-ID: <5175@ihlpf.ATT.COM>
Date: 1 Jul 88 00:05:57 GMT
References: <163@navtech.uucp> <2775@ttrdc.UUCP> <164@navtech.uucp>
Reply-To: nevin1@ihlpf.UUCP (00704a-Liber,N.J.)
Organization: AT&T Bell Laboratories - Naperville, Illinois
Lines: 47

In article <164@navtech.uucp> mark@navtech.UUCP (Mark Stevans) writes:

>	"The space requirement of any given C structure may be easily
>	optimized by reorganizing the structure fields in order of decreasing
>	base type size."

This is not (necessarily) true!  For iinstance:

sizeof(long) === 8
sizeof(short) === 5
sizeof(char) === 1

Also suppose that alignment for shorts and longs occurs on even addresses
(two byte boundaries), while chars can align on single byte boundaries.

With your method, a structure containing 1 long, 2 short, and 2 char would
be decalred in the following way:

struct mark
{
	long	long1;
	short	short1;
	short	short2;
	char	char1;
	char	char2;
};

would take up 8 (long) + 5 (short) + 1 (fill) + 5 (short) + 1 (char)
	+ 1 (char) = 21 bytes.

If it is declared as:

struct nevin
{
	long	long1;
	short	short1;
	char	char1;
	short	short2;
	char	char2;
}

would only take up 20 bytes, since no fill byte is needed.
-- 
 _ __			NEVIN J. LIBER	..!ihnp4!ihlpf!nevin1	(312) 510-6194
' )  )				You are in a little twisting maze of
 /  / _ , __o  ____		 email paths, all different.
/  (_</_\/ <__/ / <_	These are solely MY opinions, not AT&T's, blah blah blah