Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!microsoft!jimad From: jimad@microsoft.UUCP (Jim ADCOCK) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: <57008@microsoft.UUCP> Date: 28 Aug 90 18:06:50 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> Reply-To: jimad@microsoft.UUCP (Jim ADCOCK) Organization: Microsoft Corp., Redmond WA Lines: 180 In article pcg@cs.aber.ac.uk (Piercarlo Grandi) writes: >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. I think it would be best to let Bjarne speak for himself directly on this issue. My impression is that his second book is carefully and deliberately worded to allow wide latitude in the implementation of the language. >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? Certainly the fact that C++ is by far the most popular OOPL language has something to do with it. [I wouldn't call C++ "fashionable" though -- I'd call it pragmatic. Eiffel and Self would be the "fashionable" languages, to my mind.] But also the fact remains, if one really wants to write real world commercial OO software, C++ is really the only language up to the task. [IMHO] >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. Clearly I disagree with your assessment of Obj-C. And C++. >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. I think you have this backwards. In the absense of good optimizers, people have to program around the limitations of their individual compilers, and hand optimize code for a particular situation, keeping it from being reusable. I don't particularly like pragmas, but I think they may be an acceptable compromise to warn a compiler when people insist on writing hacks that rightfully would fall outside the language. Companies that design portable compilers should tend to show a bias towards keeping the language such that making portable compilers is easy. Companies that design compilers for a particular CPU or OS should tend to show a bias towards making the language highly optimizable. We should not be surprised if a tension between these two goals shows up as part of the standardization process. [standard disclaimer] >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. Agreed. But does such code actually party based on the layout of a particular CPU's registers or ports? -- I think not. >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... Hm. I would think that now that C++ is the leading OOPL it needs to try to meet the needs of the majority of its users. I would not think that the majority of people need or want to maintain intimate control of their compiler. I'd think the average OO programmer would be working on a much higher level, using libraries others provide to do the bit twiddling. Once these low level libraries are written, the many others can build on these efforts. >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. If this opinion is correct, why would it not win in the marketplace? Why cannot C++ programmers just say, hm, FuzzCo's Ultra-C++ compiler isn't worth the time/size/money or complexity. I'll just use this TinCo Tiny C++ compiler instead? Whats wrong with letting the marketplace decide these tradeoffs? Why is it necessary to force your particular engineering design tradeoff beliefs into the language definition itself? >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. Actually, my conclusion is not that compilers may reorder at will. My conclusion is that compiler designers should have the freedom to decide these issues for themselves, and that C++ programmers should have the freedom to choose the compiler that then best serve their needs. Nothing I have proposed forces a vendor to offer a large, complicated compiler. Again, compilers already have the right to almost completely reorder a structure at will. The *only* constraint in E&S is that within a labeled section, member variables declared later will be places at "higher" addresses. The reason given for this constraint is backwards C compatibility. Well, the constraint is so weak as to offer little in backwards C compatibility. So my suggestion is to remove it, or to relegate it to those features of the language specifically addressing backwards compatibility. To my eye, having both the extern "C" construct, and a separate field ordering restriction applied accross the language, looks like a simple historical oversight, that should be fixed. >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). Then don't buy or use such compilers. Use one that suits your fancy. I don't propose to try to force a compiler you don't like on you. Why do you want to force your particular compiler design beliefs onto the compiler I would use? Again, my proposal is to leave this issues to the sensibilities of the compiler designers, and the power of the marketplace. Over the near term, I'd be very surprised if any compiler diverges too far from the cfront object model, because the cfront object model represents the only object model that many programmers know. So there would be great market skepticism to a compiler that introduced a very different object model. However, as time goes on, other OOPLs are going to demonstrate very different object models, and I claim we want C++ to be specified with the freedom to allow compilers to incorporate the best of those new object models. And/or to allow C++ compilers be designed simply to allow compatibility to these other object models. >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. I guess from my perspective, there is clearly not one answer to this question. The tradeoff between development costs verses runtime costs is very much a function of the number of units of your program you intend to produce. If only a couple copies of a program are to be created, development cost is paramount, and runtime cost is typically unimportant. If a company makes millions of copies of a programmer however, runtime costs outweight all other factors. A company that failed to shave the last few seconds from their software in that situation would be costing society thousands, if not millions of dollars in wasted user productivity. In the first scenerio, a C++ programmer might want to use an p-coded C++ implementation that follows a minimal recompilation strategy. This might be accomplished by inheriting via reference, not embedding objects, and tagging any newly declared members on the end of an objects' section. This is one object model totally different than the cfront model. In the second scenerio, a highly optimizing compiler might be used. Pragmas might be used to indicate when constants aren't. Pragmas might be used to indicate when a class is a leaf class. Compilations might be optimized on a module global basis. Smart linkers might winnow out vtable indirect calls. Fat tables, or tricks might be used. Fields might be reorganized based on profiling information. This would also lead to an object model very different from cfront. Thus, I don't believe one object model spans the needs of all C++ users [nor all systems C++ might run on -- such as a Rekursiv-like machine, or a Lisp-like machine, or a Smalltalk-like machine] So I believe it would be very short sighted to try to specify the C++ language strictly around a cfront-like object model. Let's leave our options for the future open.