Re: procedure parameter struct order
From: Dave Thompson (david.thompson1_at_worldnet.att.net)
Date: 03/01/04
- Next message: Dave Thompson: "Re: Comments requested: brief summary of C"
- Previous message: Dave Thompson: "Re: Loops, switches, embedded returns"
- Next in thread: Richard Bos: "Re: procedure parameter struct order"
- Reply: Richard Bos: "Re: procedure parameter struct order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Mon, 01 Mar 2004 07:08:36 GMT
On Tue, 24 Feb 2004 10:06:07 GMT, rlb@hoekstra-uitgeverij.nl (Richard
Bos) wrote:
> Yoon Soo <y00ns00@gmx.net> wrote:
>
> > My question was exactly: if a struct is passed as an argument of a
> > function, the members of this struct would always have the same order on
> > the stack..or to be more exact, if the function expects to find the
> > members in the order they are declared.
>
> No. In particular, as has already been written by several people, you do
> not even know whether the arguments are passed on the stack in the first
True. Or if there even is a (single) stack as such, although to allow
functions to be recursive, which *is* required, there must be some way
to make automatic (aka local) variables operate stackishly.
> place. All you know is that to code using C pointers, it must appear as
> all members are at the same place in memory. Even this might mean that
Not quite the same place, that would be a union. In a contiguous chunk
of memory than can be memcpy'ed to another struct object of the same
type and work, yes; and with member addresses/offsets in ascending
order, but as noted elsethread possibly skipping padding.
> the struct is copied into some (cheap, fast, plentiful) allocated
> memory, and a hidden pointer to this copied struct is passed on the
> (slow, small) stack.
Stacks are rarely slow and small, usually they are fast -- often
distinctly faster than general memory, because of better cache
locality -- but may be small(ish). Or, often a pointer (but not a full
struct) can be passed in register(s), which are usually (very) small
and (very) fast.
> But even when the stack is used, you do not know that the whole stack is
> passed, or in what order. For example, take this code:
>
> struct rectangle { [snipped]
> }
>
(Nit: missing semicolon)
> int rect_size(struct rectangle r)
> {
> if (r.hatching==PAT_BLANK)
> return 0;
> return r.width*r.heigth;
> }
>
> Since nothing in the function references anything else in the structure,
> and there is no possible way for you to detect the difference, the
> compiler would be quite correct if, behind the scenes, all it pushed on
> the stack were the hatching, width and heigth members, and adjusted the
> object code for the function accordingly. The program would function
> identically, except that it spends a few cycles less pushing and popping
> needless struct members. No problem, in ISO C.
Although this function could be called from a separately compiled
"module" (strictly, translation unit), and the compiler, or linker, or
something, would have to make sure that such calls also do that same
optimization, which on many/most? systems is so hard as to be
practically impossible. Now if you made the function 'static', it
would be somewhat more likely. In fact, if the definition is visible
during compilation -- as it must be, if static -- there's a fair
chance it will be inlined, and nothing will be pushed at all. Perhaps
even a slightly better chance in C99 if you *specify* 'inline'.
(PS- it's spelled 'height', or spelt depending on your location.)
- David.Thompson1 at worldnet.att.net
- Next message: Dave Thompson: "Re: Comments requested: brief summary of C"
- Previous message: Dave Thompson: "Re: Loops, switches, embedded returns"
- Next in thread: Richard Bos: "Re: procedure parameter struct order"
- Reply: Richard Bos: "Re: procedure parameter struct order"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
