Path: utzoo!utgpu!watserv1!watmath!att!occrsh!uokmax!apple!julius.cs.uiuc.edu!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Controlling structure layout (Re: Randomly ordered fields !?!?)
Message-ID: <57316@microsoft.UUCP>
Date: 11 Sep 90 17:46:23 GMT
References: <1990Aug28.173553@bert.llnl.gov> <1990Sep1.131041.15411@zorch.SF-Bay.ORG> <1990Sep4.163132@bert.llnl.gov> <1990Sep6.194543.7685@zorch.SF-Bay.ORG>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 50

In article <1990Sep6.194543.7685@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>As Ron noted, C "allows" arbitrary amounts of padding between
>fields in a structure, but "nobody" does anything but the sensible
>single or double word alignment padding.  Let's pick one layout
>now in use (take the obvious hits if there is a big endian, little
>endian conflict), and make it the standard (or, make the standard
>such that I can force e.g. "two byte alignment", "four byte alignment"
>or whatever, so long as I am consistent about it among the modules
>accessing the data; sounds like an object candidate to me! ;-), and
>publish it for all compiler writers to implement as a choice allowed
>forthe user who needs this level of control.

Let's assume for the moment we're just talking "C" structures, and leave
"C++" issues out of it.

Even with just good old "C" structures you run into the following problems:

Big endian, Little endian, or something in between?  There's more than
two flavors of byte ordering -- two ways to pack two bytes into a short, but
24 ways to pack four bytes into a long.  And yes, there are machines using
some of these non-endian approaches. 

Double byte, quad byte alignment?  Some machines "only" support double 
byte alignment.  Some "only" support quad byte alignment.  [Some only 
support octal byte alignment]  A compiler can't practically offer you
a choice if the underlying hardware doesn't support it.

Bit field ordering.  Pack from the low end, or the high end?  Signed or
not?  32bit max, or 16bit max?  32bit subfield max, or 16bit subfield max?
Pack over a double byte boundary, or break?

Signed chars, or not?

16bit ints, or 32bit ints?

0:16, 16:16, 16:16+16, 0:32, 0:32+16, 16:32, 16:32+16, 0:48, or 0:64bit ptrs? 
Or what combination thereof allowed in structures?

....So my claim is that there is no format that can be agreed upon
that will run on a large percentage of the machines with acceptible performance.

-- And this is just with issues of "C" structures -- no inheritence issues,
no vtable, vbase issues, member ptrs, no calling convention issues, etc. 
that arise in C++.  Ellis and Stroustrup do a good job of pointing out a few 
of the implementation choices that can be made, although they barely scratch 
the surface.

I counterpropose that programmers program so as to avoid the need for 
bitwise-equivalence across machines or compilers.  Because in simple reality, 
its never going to exist.