Portability of passing/operating on structures...

der Mouse mouse at mcgill-vision.UUCP
Fri Oct 28 07:53:22 AEST 1988


>From <8810111934.AA21941 at ucbarpa.Berkeley.EDU>,
 by U23405 at UICVM.Berkeley.EDU (Michael J. Steiner)
>> Is it considered portable to do the following things with
>> structures or unions?
>>     -pass them (by value) to functions
Yes.
>>     -have functions which return them
Yes.
>>     -assign them (=)
Yes.
>>     -test them (structures only) for equality with ==
No.

>From <2685 at hound.UUCP>, by rkl1 at hound.UUCP (K.LAUX)
> *Why* would you want to do this anyway?  It is far easier to use
> pointers (and much more efficient).

It is often easier to use by-value, and in some cases it isn't much, if
any, less efficient.  If you use pointers all the time, you have to
manage the storage for the pointers to point to.  If you use structures
by value, you can let the usual variable allocation mechanisms handle
this for you.  An example might be complex numbers.

> If you are trying to get the compiler to automatically generate code
> to copy the fields of the structure, *don't*.

Why not?  The compiler knows better than you do whether it can use
clever machine-dependent tricks to get a fast copy....

> What you can do is declare a pair of *unsigned char* pointers and
> cast the addresses of the source and destination structures to
> 'unsigned char', then do a short loop to copy byte by byte based on
> 'sizeof (struct)'.

This will probably.  But on a machine with an addressing unit larger
than a char, you will pay a heavy efficiency penalty for this.  On
machines with a fast block move instruction, this almost certainly
won't use it, and you take a performance hit again.  That's what I
meant above: the compiler knows all these tricks, or ought to, and can
use the fastest one that applies.

> As for testing equality of the contents of two unions/structures, go
> through the effort of testing field by field -  you can't go wrong
> this way.

More to the point, you can go wrong if you do a byte-compare, because
of holes.  It seems reasonable to me for equality testing of structures
to generate code to compare all the members, but there are difficulties
like what to do when with arrays of char; presumably this is why this
isn't done.

					der Mouse

			old: mcgill-vision!mouse
			new: mouse at larry.mcrcim.mcgill.edu



More information about the Comp.lang.c mailing list