Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!asuvax!ncar!midway!tank!stephen From: stephen@estragon.stars.flab.Fujitsu.JUNET (Stephen P Spackman) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: Message-ID: Date: 3 Sep 90 03:57:43 GMT References: <1990Aug27.152540@bert.llnl.gov> <1990Aug28.211752.24905@zorch.SF-Bay.ORG> <1990Aug28.173553@bert.llnl.gov> <1990Sep1.131041.15411@zorch.SF-Bay.ORG> Sender: news@midway.uchicago.edu (News Administrator) Organization: Fujitsu Laboratories Ltd., Kawasaki, Japan. Lines: 71 In-Reply-To: xanthian@zorch.SF-Bay.ORG's message of 1 Sep 90 13:10:41 GMT In article <1990Sep1.131041.15411@zorch.SF-Bay.ORG> xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: howell@bert.llnl.gov (Louis Howell) writes: > xanthian@zorch.SF-Bay.ORG (Kent Paul Dolan) writes: >|> [...] 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, [...] 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. I feel a little odd posting here, being radically anti-c++ myself, but I *did* drop in and something about this thread is bothering me. (-: (honestly!) Look, if you're going to take an ugly language and then bolt on a kitchen sink and afterburners :-), why not put in the one thing that is REALLY missing from C: * STANDARD BINARY TRANSPUT * Can't we have the compiler provide the trivial little shim function that will read and write arbitrary data structures to binary streams? Most operating systems now seem to have standard external data representations, which are intended for precisely this kind of purpose, and a "default" version would not be hard to cook up (or appropriate). The runtime overhead is usually dwarfed by transput cost, and you get better RPC support as a freebie. That way only the *external* representation format needs to be specified, and the runtime image can be as zippy as it please. You can even read and write code if you're willing to interpret it - or call the compiler, if you've got it kicking around. >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. >[...] Ahem. Offhand I can think of any number of HETEROGENEOUS shared-memory machines. Mainframes have IOPs. Amigae share memory between bigendian, word-align 680x0s and littlendian, byte-align 80x86es (-: amusingly enough you can do things about bytesex by negating all the addresses on one side and offsetting all the bases, but... :-). Video processors with very *serious* processing power and their own (vendor-supplied) C compilers abound. Now, I'll grant, a *real* operating system, (-: if someone would only write one for me, :-) would mandate a common intermediate code so that vendors only supplied back-end, but even then I'm NOT going to pay interpretation overhead on all variable accesses on, say, my video processor, my database engine, by graph reduction engine and my vector processor, just because my "main" CPU wants a certain packing strategy! There *must* be a mechanism for binary transmission of binary data, this must *not* be the programmer's responsibility, and while localising all code generation in the operating system's caching and replication component is the obvious thing to do, (a) that day hasn't arrived yet and (b) the compiler will STILL have to get involved and generate the appropriate type descriptors and shim functions. stephen p spackman stephen@estragon.uchicago.edu 312.702.3982