Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!samsung!sdd.hp.com!ucsd!pacbell.com!tandem!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: Message-ID: <1990Aug28.211752.24905@zorch.SF-Bay.ORG> Date: 28 Aug 90 21:17:52 GMT References: <56940@microsoft.UUCP> <1990Aug27.212649.16101@csc.ti.com> <1990Aug27.152540@bert.llnl.gov> Organization: SF Bay Public-Access Unix Lines: 28 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.