🚀 go-pugleaf

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.

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