Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!tut.cis.ohio-state.edu!snorkelwacker!ai-lab!wookumz.ai.mit.edu!roland From: roland@ai.mit.edu (Roland McGrath) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: Date: 20 Aug 90 23:22:16 GMT References: <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> <1229@lupine.NCD.COM> Sender: news@wheaties.ai.mit.edu Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome) Lines: 144 In-reply-to: rfg@NCD.COM's message of 18 Aug 90 07:46:50 GMT In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: The question really should be "How much harder would doing some reasonably common programming task, X, be if feature (or constraint) F were ommited from the language?" and also "How difficult is it for a typical implementor to implement feature (or constraint) F?" I disagree. I don't see why difficulty of implementation should be an issue in the language standard. It's not a list of implementation guidelines; it's a standard for how the language behaves. You seem to presume that the people contributing to the standard will be at least as clever as any implementor of the language. I find this a completely ridiculous presumption. Just because you can't think of a way to do something, you want to disallow others from attempting it. I can't think of a way to do it either, but I would fight the the right of others to make the attempt. In the case of a constraint which would require compilers to maintain the programmer-specified ordering of data fields, the implementation is trivially easy. (In fact, it is actually *harder* to do anything else!) So obviously lazy implementors will do what you want, and clever/hardworking implementors will do something more. Also, the usefulness of allowing the programmer to precisely specify his desired field ordering is (in my opinion) quite large. Although I think I consider this less useful than you do, I am in favor of retaining a way to force a given field order. Using: extern "C" { struct foo { char elt0; int elt1; }; } does this quite well. As I noted in a prior posting, programmers may often need to do this when dealing with data formats dictated by outside constraints (e.g. existing disk formats, existing datacomm protocols, memory mapped I/O devices, and (last but not least) layouts mandated by external routines (e.g. from libc.a) written in other languages such as C). Indeed true. This is why I advocate giving them a way to do so, shown above. >>I personally find the rule cited above intensely offensive because it gives >>the compiler licence to thwart the will of the programmer (who is supposed >>to be in control after all). I don't like that one little bit! > >Actually, the will of this programmer is that C++ compilers generate the >fastest and most compact code possible from my class declarations. Are you suggesting that it may be possible to generate more efficient executable code if arbitrary field re-ordering (by the compiler) is allowed? If so, are you prepared to give realistic (not contrived) examples of such improvements? I'm not so prepared. Are you prepared to prove it impossible? If (on the other hand) you are only suggesting that a compiler could possibly pack fields in some better order than I can, let me assure you that you are wrong. If you would care to organize a test, I'll be glad to pit my brain against your compiler in a "structure packing" test any day of the week. Given that all present compilers are bound by the present rules, this idea is somewhat ridiculous. I expect the standard to outlive present or near-future implementations, however. Otherwise, what's the point of having a standard? As a matter of fact, I surmize that the intelligence necessary to do good structure packing is not even beyond the reach of your common garden slug. This fact makes me all the more confused about your insistance that you want compilers to do this for you. Are you low-rating yourself? :-) Where do you find these garden slugs with absolute prescience of all possible future computer architectures and C++ implementations? Right now, if I have the following C code: struct s { unsigned field1:24; unsigned field2:8; }; and this is in a program running on a 68000, I can get C compilers from at least a dozen vendors that will lay this out *exactly* the same way. Thus, I have vendor independence. That (and portability) are worth money to me. This is an excellent example. Since we are speaking of C++, and the example is C code, you can simply put it within `extern "C"' and have all the guarantees you now have with the C code. Now I find out that I've lost this with C++, and I've gotten virtually nothing in return. :-( You have not lost this functionality. You simply must use a slightly different construct. Since you are using a significantly different language, you should consider yourself lucky that the necessary change is so minor. By my standards, the possibility of many new optimizations as yet unconceived of is not "virtually nothing". >... Or alternatively, >probably just about any vendors compiler with all optimizations turned >off will fullfill your requirements. Not if it is not *required* by the standard!!! Quite true. An excellent argument for why field reordering should not be allowed within `extern "C"'. >Again, why should everyone's C++ compiler have to generate slower, >more memory intensive code in order to meet the needs of people who >feel they want to maintain intimate control over their compiler? >Why can't they just buy a compiler that gives them that control? Again, you have presented no evidence whatsoever that obeying the programmer's wishes with regard to field ordering will result in slower (or "more memory intensive") code in any real programs. Until you do, this argument should be viewed as simply a red herring. You again presume foreknowledge of all possible future implementations. I find such arrogance surprising from an otherwise reasonable person. I believe that this argument is bogus, and that it has no basis in fact. I consider it a fact that some C++ compiler implementor may in the future come up with a way to improve efficiency through field reordering. Until such a way is proven impossible, this remains a fact. Programmers need not suffer any performance penalty whatsoever in order to have the compiler obey their wishes. This is true if and only if your definition of "performance" includes only run-time program speed. While this type of performance is of great concern to me, of equal concern is programmer performance. Programmer performance degrades greatly when the programmer is forced by constraints of the language to do work that the compiler could be doing. -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland