Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!uakari.primate.wisc.edu!aplcen!uunet!mcsun!ukc!dcl-cs!aber-cs!athene!pcg From: pcg@cs.aber.ac.uk (Piercarlo Grandi) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: Date: 25 Aug 90 15:02:56 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> Sender: pcg@aber-cs.UUCP Organization: Coleg Prifysgol Cymru Lines: 85 In-reply-to: jimad@microsoft.UUCP's message of 16 Aug 90 19:20:16 GMT On 16 Aug 90 19:20:16 GMT, jimad@microsoft.UUCP (Jim ADCOCK) said: jimad> Actually, the will of this programmer is that C++ compilers generate the jimad> fastest and most compact code possible from my class declarations. It jimad> is not C++ compilers that are tharting this will, but rather people who jimad> want to continue using C++ as a C assembly language. These include Stroustrup, apparently. See the introduction to his first C++ book... C++ *has been designed* as an OO MOHLL/SIL. jimad> I want to be able to use C++ as a fast, efficient object oriented jimad> language. This requires compilers that have great optimization, jimad> and great freedom to optimize. Why don't you use Self? Objective C or Eiffel? Just because C++ is fashionable? IMNHO C++ is just about the only OO around with widely available compilers designed as a SIL/MOHLL . Let's keep it that way. People who want a more applications oriented language should choose something like one of the languages above. As soon as GNU CC 2.0 will be released I think that Objective C will grow very much in popularity, IMNHO. jimad> There continues this division between C/C++ people who want a compiler jimad> to "do what I say" verses "do you best optimizations." I think this jimad> issue should be addressed in the marketplace -- not in the language. This of course kills any idea of portability. You programs start to have semantics that depend, by construction, both on the compiler and the language. This is IMNHO *very* bad, vide the abominable pragma pandora box of Ada and Ansi C. It may be very good for compiler vendors, though, especially those that have or think will have a large market share, and want to get entrenched into it. Thank goodness AT&T does not reason that way, because they are too large and diverse an organization themselves. jimad> If you want to use C++ to play with machine registers, then jimad> portability is not an issue to you anyway. Ah no, not so easy. One can provide, thanks to the wonders of separate compilation or conditional preprocessing, both a slow portable version and a fast one that will not work on every implementation, but is still expressed as much as possible in the base language. jimad> Again, why should everyone's C++ compiler have to generate slower, jimad> more memory intensive code in order to meet the needs of people who jimad> feel they want to maintain intimate control over their compiler? Maybe because the language has been designed for the latter group... And because many times the compiler cannot understand the program better than they do anyhow, or requiring the compiler to do it is not a win-win situation, e.g. results in larger, slower, less reliable compilers. A language _definition_ should be independent of compiler implementation issues, but the language _design_ should well take into account such pragmatics. "advanced" features are easily botched; consider Ansi C and 'volatile', whose _omission_ makes a program undetectably erroneous, and that otherwise exists almost only to assist the optimizer. This particular problem does not apply to field reordering. There is another problem though: that it makes the binary output of programs compiled with different compilers or releases of the same compiler potentially incompatible. Do we really want to force using XDR or ASN.1 throughout? Consider also the conclusion that you and Guilmette seem to be reaching: the compiler may reorder at will by default, as long as there is some mechanism to override it. This seems the best solution, as long as you do not see the additional cost in complexity/unreliability of the manual, of the compiler, of the program build process. You have to weigh these things carefully, and if you do not, you go down the slippery path Ansi C has gone. So, are today's C/C++ multimegabyte compilers significantly more reliable and faster and generate better quality code than those that run in 64KB[+64KB]? IMNHO no, or at least not enough that the changed pragmatics should influence for design of the language (as has happened, for the worst, with Ansi C). But maybe I am wrong, and the relative cost of compile time resources (time, space, programmer confusion, reliability) vs. runtime speed have changed so much that a modest increase of the latter can be economically bought at the price of a large increase of the former. -- Piercarlo "Peter" Grandi | ARPA: pcg%uk.ac.aber.cs@nsfnet-relay.ac.uk Dept of CS, UCW Aberystwyth | UUCP: ...!mcsun!ukc!aber-cs!pcg Penglais, Aberystwyth SY23 3BZ, UK | INET: pcg@cs.aber.ac.uk