🚀 go-pugleaf

>>>>> On 31 Jul 90 23:13:11 GMT, jeremy@cs.ua.oz.au (Jeremy Webber) said:
Jeremy> The ability for a compiler to re-order the elements of
Jeremy> structures/unions is a useful optimization.  I would argue that any
Jeremy> code which writes structures to a data file is non-portable.

True.  Even if the ordering is identical, the alignment may vary.  However,
alignment is not _likely_ to vary between systems using the same CPU,
although it still _can_ vary due to compiler differences.

Jeremy> If data is to be portable it should *always* be written element by
Jeremy> element, preferably in ASCII.

If your program isn't already I/O bound, this is an excellent strategy, and
I highly recommend it as the default strategy.

Jeremy> The programmer should never assume specific structure ordering,
Jeremy> except in the case of bit field specifications, which can override
Jeremy> the compiler's defaults.

Even this can fail, unless all the world is a 32 bit int.  Seriously, many
programs have to bang hardware which may not pack data in the "optimized"
form.  Perhaps this (and portability between compilers) is partly why order
of inheiritance became defined under C++ 2.0.

I also suspect reordering members between parents in a derived class such
that their elements are interleaved, would present a run time nightmare for
the C++ implementor.  Perhaps one of the implementors out there would care
to comment.

Jeremy> This is the sort of hackery which causes many C programs to fail!

...and many operating systems to work.

#pragma STD_DISCLAIMER
--
Chuck Phillips  MS440
NCR Microelectronics 			Chuck.Phillips%FtCollins.NCR.com
Ft. Collins, CO.  80525   		uunet!ncrlnk!ncr-mpd!bach!chuckp