structure layout question

[kyle york]

Greetings,

Why does the C standard require the members of a structure not be
re-ordered (6.2.5.20)? Padding is allowed, and platform dependent, which
means one cannot rely on the exact layout anyway, so what's the point?

Without this restriction the compiler could layout the structure in the
most efficient way possible, for some definition of efficient. It would
be easy enough to turn this reordering off with a compiler specific
pragma as is often done with padding.

--
Kyle A. York
Sr. Subordinate Grunt

[Malcolm McLean]

"Ian Collins" <ia******@hotma il.comwrote in message

>If you need a generic function, it accepts a void * together with some
information telling it what type of packet was received. That probably
entails a call to malloc() to receive the data, but that doesn't matter
on a modern system.

It sure does on the 'modern' 8 and 16 bit embedded devices I work with!

But your 8 bit embedded device runs a watch or a calculator or something
similar. It doesn't try to run Pacman, which is what we did on 8 bit jobs in
the olden days. Even on small devices, you rarely need to stretch the
processor any more.

--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm

[Doug]

On 1 Mar, 21:45, Eric Sosman <Eric.Sos...@su n.comwrote:

Doug wrote On 03/01/07 16:24,:

On 1 Mar, 20:30, "Stephen Sprunk" <step...@sprunk .orgwrote:

>"kyle york" <[e-mail] wrote in message

<snip>

>The standard's wording guarantees that two structs defined with the same
initial elements will be laid out the same way in memory

<snip>

Ben, Walter,

I'm interested in your discussion about 'minimal' vs 'appropriate'
padding. If we accept Stephen's statement above (which I *think* is
true), then I think this means that there must be a canonical way to
lay out a structure.

If this canonical method is compiler-specific, then I guess
appropriate might not equal minimal.

But I read the standard to say that all compilers (on a given arch)
should lay the structure out in memory the same way (without use of
#pragma pack, etc.). (Thus I can use a 3rd party library without
caring about what it was compiled with.)

No, the C Standard has no concept of an "arch;" it talks
only about "implementation s." Every implementation must meet
the requirements of the Standard, but can do so in any way it
chooses. There is no guarantee (in the C Standard) that gcc
and Frobozz Magic C will make identical decisions, even if
they run on the same machine. There is no guarantee even
that a single compiler will make the same decisions when run
with different option flags! As far as the C Standard can
see, "gcc" and "gcc -fomit-frame-pointer" are two distinct
implementations , and need not be compatible.

That said, most platforms publish some kind of "Applicatio n
Binary Interface" that specifies some of the decisions that the
C Standard leaves unmade. If you're supposed to pass some kind
of struct to a system service, the struct must be laid out in
thus-and-such a way, and all compilers on that platform had
better toe the line. So the standard you mention usually does
exist -- except that it's not The Standard, and it may or may
not describe things in terms of language-specific constructs
like structs.

Putting this all together, surely that means that all compilers (on
the same arch) must share the same canonical method of laying out a
structure? If so, then surely 'minimal' is the only sensible way to
agree on that canonical method?

I don't see how "canonical" implies "minimal."

Or am I way off base?

I once saw a relief pitcher enter a baseball game and seal
the win without throwing even one pitch. The Red Sox were down
by two in the top of the ninth in Baltimore, with two out and a
man on base. Carlton Fisk singled, advancing the runner to
third and putting himself on first as the tying run. In came
the reliever to face the next batter, the potential go-ahead run.
He took his warm-up throws, got his sign from the catcher, and
threw to first to pick off Fisk and end the game.

He would *definitely* have had you flat-footed. ;-)

--
Eric.Sos...@sun .com- Hide quoted text -

- Show quoted text -

*Now* I remember why I don't bother posting here.

[Dave Vandervies]

In article <11************ **********@p10g 2000cwp.googleg roups.com>,
Doug <Du****@blueyon der.co.ukwrote:

[snip almost 80 quoted lines]

>*Now* I remember why I don't bother posting here.

Oh, don't let us scare you off. Once you've grown a moderately thick
skin, CLC is an *excellent* tool for converting incomplete or incorrect
knowledge about C into as much as you ever wanted to know (and then some).
But please do remember to trim unnecessary quoted materal like signatures
and text that isn't relevant to what you're saying in your post.
dave

--
Dave Vandervies dj******@csclub .uwaterloo.ca

Odd, that. My programs don't tend to make my computer systems fall over.
--Richard Heathfield in comp.lang.c

[Ian Collins]

Malcolm McLean wrote:

>
"Ian Collins" <ia******@hotma il.comwrote in message

>>If you need a generic function, it accepts a void * together with some
information telling it what type of packet was received. That probably
entails a call to malloc() to receive the data, but that doesn't matter
on a modern system.

It sure does on the 'modern' 8 and 16 bit embedded devices I work with!

But your 8 bit embedded device runs a watch or a calculator or something
similar. It doesn't try to run Pacman, which is what we did on 8 bit
jobs in the olden days. Even on small devices, you rarely need to
stretch the processor any more.

Nope, they control complex power systems with lots of inter device
communications.

--
Ian Collins.

[Eric Sosman]

Dave Vandervies wrote:

In article <1172773547.747 71@news1nwk>,
Eric Sosman <Er*********@su n.comwrote:

> Under certain conditions, different struct types
that share a "common initial subsequence" of elements
can be accessed through a pointer to either type, so
long as the accesses are to the common elements. That's
another useful property.

Aren't the condititions for that pretty much "You're not running it on
the DS9k"?

As far as I can see, yes. But my eyes aren't as good
as they once were ...

--
Eric Sosman
es*****@acm-dot-org.invalid

[Richard Bos]

dj******@caffei ne.csclub.uwate rloo.ca (Dave Vandervies) wrote:

In article <1172773547.747 71@news1nwk>,
Eric Sosman <Er*********@su n.comwrote:

Under certain conditions, different struct types
that share a "common initial subsequence" of elements
can be accessed through a pointer to either type, so
long as the accesses are to the common elements. That's
another useful property.

Aren't the condititions for that pretty much "You're not running it on
the DS9k"?

There's also "The structs are not members of the same union". If that is
the case, you can get away with it even on a DS9K.

Richard

[Richard Bos]

"Malcolm McLean" <re*******@btin ternet.comwrote :

"Ian Collins" <ia******@hotma il.comwrote in message

With modern processors and modern programming conventions, it should not
be necessary to rely on the arrangement of structure elements in memory.
As you say, doing so is fraught with portability bugs. But legacy code
needs to be supported, which is more important than minor gains in
efficiency you might obtain by allowing the compiler to organise the
elements itself.

No matter how modern the code is, the problem of disambiguation of
structures in a union remains.

Generally you don't need unions.

Generally you don't _need_ for loops. Both they and unions can be very
useful, though.

A 256-byte packet arrives. Instead of trying to define the bit pattern with
a C union, you can take the first two bytes, switch on the type, and then
create the appropriate structure, reading that data packet one byte at a
time.

That's one situation where using a union is not the right solution, yes.

Now try, for example, creating a virtual world full of creatures, all of
which have common data for age, amount of food eaten, and size; but some
of which will need a member for thickness of fur, while others will need
one for number of segments. Unions of structs will come in _very_
useful.

Richard

[Eric Sosman]

Richard Bos wrote:

dj******@caffei ne.csclub.uwate rloo.ca (Dave Vandervies) wrote:

>In article <1172773547.747 71@news1nwk>,
Eric Sosman <Er*********@su n.comwrote:

>> Under certain conditions, different struct types
that share a "common initial subsequence" of elements
can be accessed through a pointer to either type, so
long as the accesses are to the common elements. That's
another useful property.

Aren't the condititions for that pretty much "You're not running it on
the DS9k"?

There's also "The structs are not members of the same union". If that is
the case, you can get away with it even on a DS9K.

You probably meant "are" instead of "are not."

--
Eric Sosman
es*****@acm-dot-org.invalid

[Malcolm McLean]

"Richard Bos" <rl*@hoekstra-uitgeverij.nlwr ote in message

>
That's one situation where using a union is not the right solution, yes.

Now try, for example, creating a virtual world full of creatures, all of
which have common data for age, amount of food eaten, and size; but some
of which will need a member for thickness of fur, while others will need
one for number of segments. Unions of structs will come in _very_
useful.

I'd handle that one like this

typedef struct
{
void **ptr;
int *type;
int N;
} CREATURE;

void *isa(CREATURE *cr, int type)
{
int i;

for(i=0;i<cr->N;i++)
if(type == cr->type[i])
return ptr[i];

return 0;
}

That way a creature can be a quadruped, say, and also a mammal and also a
riding animal.
However you might decide that dophins are honourary fishes, so they have the
"mammal" interface but not the "quadruped" one. Then you might allow
ostriches to be rideable, in which case they would have the "riding animal"
interface but not the "mammal" one.

Your way will execute faster and is maybe better for a simple system with
only a few creatures and interactions, but it won't scale as easily.
--
Free games and programming goodies.
http://www.personal.leeds.ac.uk/~bgy1mm