Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: <1229@lupine.NCD.COM> Date: 18 Aug 90 07:46:50 GMT References: <56268@microsoft.UUCP> <1070@lupine.NCD.COM> <56638@microsoft.UUCP> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 126 In article <56638@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes: >In article <1070@lupine.NCD.COM> rfg@ncd.com writes: >>There already exists a defined way within the language to "turn off the >>standard C++ field ordering restrictions". >> >>Section 9.2 (page 173, middle of the page) in E&S says: >> >> "The order of allocation of nonstatic data members {which are} >> separated by an access specifier is implementation dependent (11.1)". > >Yes. So given that access specifiers and/or inheritence can bust people's >expectations on packing order, why maintain restrictions on packing order >at all? Perhaps you missed my point. I was suggesting that the rule quoted above be REVOKED and DELETED from the final ANSI standard. >... What percentage of C++ programmers need to diddle machine >registers, and how often? What percentage of C++ programmers *need* to use default parameters? What percentage of C++ programmers *need* to use multiple inheritance? In the case of each of these language features a good case can be made that 0% of C++ programmers *need* these features. Should we therefore chuck them out of the language? I think not. 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?" 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!) Also, the usefulness of allowing the programmer to precisely specify his desired field ordering is (in my opinion) quite large. 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). >>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? 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. 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? :-) >... There continues to be a division between those who want a compiler >to "do what I say" verses "do you best optimizations." I think this >issue should be addressed in the marketplace -- not in the language. >If you want a C++ compiler that acts just like C that acts just like >assembler, then surely the marketplace will offer such a compiler from >some vendor. If you want to use C++ to play with machine registers, >then portability is not an issue to you anyway. You have made a rash generalization which is untrue. I may be concerned with data formats (on disk or in a communications channel) and I may also be concerned with portability. Furthermore, I may even be diddling machine registers and I may *still* be concerned with portability!!! Obviously, you have never seen any C code which drives some specialized peripherial chip (e.g. an ethernet controller) which gets ported from one CPU to another as that peripheral chips gets used in different kinds of systems. I have seen this though. Also, independent of the portability issue, there is also the issue of "vendor independence". Even if my code stays forever on this one system, if I find a new compiler that I think generates better code, and I buy it and install it and recompile my old code with it, I'd kinda like that old code to continue working. I don't want to see it start to core dump just because compiler writers were given the freedom to rearrange my field orderings willy-nilly and because they all choose to do it differently. 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. Now I find out that I've lost this with C++, and I've gotten virtually nothing in return. :-( >... 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!!! >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. I believe that this argument is bogus, and that it has no basis in fact. Programmers need not suffer any performance penalty whatsoever in order to have the compiler obey their wishes. -- // Ron Guilmette - C++ Entomologist // Internet: rfg@ncd.com uucp: ...uunet!lupine!rfg // Motto: If it sticks, force it. If it breaks, it needed replacing anyway.