Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!cs.utexas.edu!uunet!lupine!rfg From: rfg@NCD.COM (Ron Guilmette) Newsgroups: comp.std.c++ Subject: Re: Randomly ordered fields !?!? (Was: "packed" objects) Message-ID: <1315@lupine.NCD.COM> Date: 24 Aug 90 06:29:04 GMT References: <56638@microsoft.UUCP> <1229@lupine.NCD.COM> Organization: Network Computing Devices, Inc., Mt. View, CA Lines: 73 In article roland@ai.mit.edu (Roland McGrath) writes: +In article <1229@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes: + + 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. In a separate posting, I have scaled back my desires based upon your persuasive arguments. Let the clever/hardworking implementors do their best! As long as I have some way to get "as written" field ordering, I'll be happy. +Although I think I consider { "as written" field ordering } 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. I agree 100%. I hope the x3j16 membership is listening. + 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? Nope. +Where do you find these garden slugs with absolute prescience of all possible +future computer architectures and C++ implementations? In the garden, of course. :-) :-) :-> + 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. Well, I don't believe that I saw that stated in E&S, but I certainly would *like* to see it in the ANSI C++ standard. +You again presume foreknowledge of all possible future implementations. I find +such arrogance surprising from an otherwise reasonable person. I have been accused of a lot of things, but never of being "otherwise reasonable". That's a first for me. :-) -- // 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.