🚀 go-pugleaf

howell@bert.llnl.gov (Louis Howell) writes:
> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes:
>|> howell@bert.llnl.gov (Louis Howell) writes:
>|> > peterson@csc.ti.com (Bob Peterson) writes:
>|> >|> [...]
>|> >|>   If a C++ compiler is able to reorder the fields of an object
>|> >|> at will, the object evolution problem faced by OODB developers
>|> >|> is substantially more complex than if field reordering is
>|> >|> restricted.  Not only can an [...]
>|> >
>|> >I don't buy this.  The representation of objects within a program
>|> >should have nothing to do with the representation of those objects
>|> >within files. [...]
>|> 
>|> [...] If you allow each compiler to make its own decisions about how
>|> to lay out a structure, then you force _any_ programs sharing data
>|> across comm links _or_ time _or_ memory space _or_ file storage to
>|> be compiled with compilers having the same structure layout rules
>|> designed in, or to pack and unpack the data with every sharing
>|> between separately compiled pieces of code, [...]

>In short, you want four types of compatibility: "comm links", "time",
>"memory space", and "file storage".  First off, "time" and "file
>storage" look like the same thing to me,

Not so.  If a program compiled with compiler A stores data in a file,
and a program compiled with compiler B can't extract it, that is one
type of compatibility problem to solve, and it can be solved with the
compilers at hand.

But if a program compiled with compiler A revision 1.0 stores data in
a file, and a program compiled with compiler A revision 4.0 cannot
extract it, that is a compatibility problem to solve of a different
type.  Mandating no standard for structure layout forces programmers
in both these cases to anticipate problems, unpack the data, and store
it in some unstructured format.  Tough on the programmer who realizes
this only when compiler A revision 4.0 can no longer read the structures
written to the file with compiler A revision 1.0; it may not be around
any more to allow a program to be compiled to read and rewrite that data.

>and as I said before I don't
>think objects should be stored whole, but rather written and read
>member by member by user-designed routines.

That is a portability versus time/space efficiency choice.  By refusing
to accept mandatory structure layout standards, compiler writers would
force that choice to be made in one way only.

>As for "memory space",
>I think it reasonable that every processor in a MIMD machine, whether
>shared memory or distributed memory, should use the same compiler.

That isn't good enough.  I've worked in shops with several million lines
of code (about 7.0) in executing software.  By mandating _no_ standards
for structure layout, you force that _all_ of this code be recompiled with
every new release of the compiler, if the paradigm of data sharing is a
shared memory environment.  Again, by refusing to make one choice, you
force several other choices in ways perhaps unacceptable to the compiler
user.  In this situation, that might well involve several man-years of
effort, and it is sure to invoke every bug in the new release of the
compiler simultaneously, and would very likely bring operations to a
standstill.  With no data structure layout standard, you have removed the
user's choice to recompile and test incrementally, or else forced him to
pack and unpack data even to share it in memory.

>This, and a requirement that a compiler should always produce the
>same memory layout from a given class definition, even in different
>pieces of code, give enough compatibility for MIMD architectures.

Not if you don't mandate that compatibility across time, it doesn't.

>Finally, the issue of communication over comm links strikes me as
>very similar to that of file storage.  If compatibility is essential,
>design the protocol yourself; don't expect the compiler to do it for
>you.  Pack exactly the bits you want to send into a string of bytes,
>and send that.  You wouldn't expect to send structures from a Mac
>to a Cray and have them mean anything, so why expect to be able to
>send structures from an ATT-compiled program to a GNU-compiled
>program?  If you want low-level compatibility, write low-level code
>to provide it, but don't handicap the compiler writers.

Same comments apply.  In a widespread worldwide network of communicating
hardware, lack of a standard removes the option to send structures intact.
One choice (let compiler writers have free reign for their ingenuity in
packing structures for size/speed) removes another choice (let programmers
have free reign for their ingenuity in accomplishing speedy and effective
communications).  Somebody loses in each case, and I see the losses on
the user side to far outweigh in cost and importance the losses on the
compiler vendor side.

Then again, I write application code, not compilers, which could
conceivably taint my ability to make an unbiased call in this case. ;-)

Kent, the man from xanth.
<xanthian@Zorch.SF-Bay.ORG> <xanthian@well.sf.ca.us>