|CProf cache profiling system available firstname.lastname@example.org (1994-10-13)|
|Re: C struct Ordering Rules (Re: Data Structure Reorganizing Optimizat email@example.com (1994-10-27)|
|Re: C struct Ordering Rules firstname.lastname@example.org (1994-10-31)|
|Re: C struct Ordering Rules email@example.com (1994-10-31)|
|Re: C struct Ordering Rules firstname.lastname@example.org (1994-11-01)|
|Re: C struct Ordering Rules email@example.com (1994-11-01)|
|Re: C struct Ordering Rules firstname.lastname@example.org (1994-11-01)|
|From:||email@example.com (John Powell)|
|Keywords:||C, design, optimize|
|Organization:||Bell Atlantic - NJ|
|Date:||Mon, 31 Oct 1994 22:39:39 GMT|
Most programs will work with struct reorganization if you do all of the
1. Recompile all the libraries that go into the program and all the objects
using whatever flags are necessary.
2. Avoid hardwiring the knowledge of offsets everywhere.
3. Use the maximally aligned data type as the first element of the struct.
int usually suffices. This will allow you to do certain special
things you may need. If you have no special needs, then just
put your structure together as necessary.
I successfully implemented generic types using principle #2, knowing that I'd
be in trouble if I didn't account for holes in the structure. Later on, all
our software was failing due to alignment problems that were resolved merely
by recompiling everything. Much later, I needed some special stuff done with
those types so I used principle #3.
At least 2 methods can be used to accomplish #2. The offsetof() macro is the
most obvious one now. When I started this, I couldn't count on offsetof() so
I used a structure break-out approach. As far as I know, the second approach
isn't taught anywhere. I "invented" it, and probably so did many others.
Return to the
Search the comp.compilers archives again.