Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!lll-winken!bert.llnl.gov!howell
From: howell@bert.llnl.gov (Louis Howell)
Newsgroups: comp.std.c++
Subject: Re: Randomly ordered fields !?!? (Was:
Message-ID: <1990Aug28.173553@bert.llnl.gov>
Date: 29 Aug 90 00:35:53 GMT
References: <56940@microsoft.UUCP> <1990Aug27.212649.16101@csc.ti.com> <1990Aug27.152540@bert.llnl.gov> <1990Aug28.211752.24905@zorch.SF-Bay.ORG>
Sender: usenet@lll-winken.LLNL.GOV
Reply-To: howell@bert.llnl.gov (Louis Howell)
Organization: Lawrence Livermore National Laboratory
Lines: 53

In article <1990Aug28.211752.24905@zorch.SF-Bay.ORG>,
 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. [...]
|> 
|> But the problem is more pervasive than just storage in _files_; you
|> have the identical situation in shared memory architectures, across
|> communication links, etc.  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,
|> surely an unreasonable requirement compared to the simpler one of
|> setting the structure layout rules once for all compilers?
|> 
|> The _data_ maintenance headaches probably overwhelm the _code_
|> maintanance headaches with the freely reordered structures
|> paradigm.

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, 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.  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.
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.

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.

Louis Howell

#include <std.disclaimer>