🚀 go-pugleaf

In an article jeremy@cs.ua.oz.au (Jeremy Webber) writes:
>In an article ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
>>
>> A) You would not be guaranteed that a data file written by a given
>> program on one machine, would be readable by the same program compiled
>> on a different machine under a different implementation of C++.
>> (Assuming that hardware and byte ordering are the same, the order
>> of structure/class elements wouldn't necessarily be the same.)
>
>The ability for a compiler to re-order the elements of structures/unions is a
>useful optimization.

Granted, it has it's uses.  So I'm in favor of having a "packed" keyword
which instructs the compiler to rearrainge the structures as appropriate,
but against making such rearraingment the default.

>I would argue that any code which writes structures to a data file is
>non-portable.  If data is to be portable it should *always* be written
>element by element, preferably in ASCII.

I work in the real world (presumably you do too), and in the real world you
don't always have enough file space to store data in 'ascii' format.  (And you
can't always "throw hardware at the problem" either!)  Nor do you have the time
that is required to write and debug thirty or more 'read/write' statements for
every one of your data structures.  THAT is wasted effort.  Far quicker and
simpler to write the data structure itself out.

Unfortunately, although I use C++ on my home computer, I haven't been able to
convince work to switch over, and even when I do, they will NOT allocate the
time required to rewrite all the old code.  This means that when/if we switch
to C++ for our new code, the data it writes MUST be compatible with the
existing code, who's data files ARE portable to a number of machines, and which
DOES use structures for reading and writting data.

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

Now that is just sooo much malarky.

No C compiler that I know of rearranges the order of elements in a structure.
Some of them adjust to 2 byte boundaries, and some to 4, due to hardware
considerations, but NONE of them change the order of the data as specified by
the source.

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

Never done it to me!  If it has to you, then I suggest that there are
compiler writers out there who are puting in "features" which are most
definitely non-standard.  Any non-standard feature should NOT be the
default but should instead be used only by the express wish of the user.

					Later!
						Edwin.