Path: utzoo!utgpu!watserv1!watmath!att!rutgers!apple!vsi1!zorch!xanthian From: xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: Message-ID: <1990Sep1.131041.15411@zorch.SF-Bay.ORG> Date: 1 Sep 90 13:10:41 GMT References: <1990Aug27.152540@bert.llnl.gov> <1990Aug28.211752.24905@zorch.SF-Bay.ORG> <1990Aug28.173553@bert.llnl.gov> Organization: SF Bay Public-Access Unix Lines: 95 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.