Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!super!rminnich From: rminnich@super.ORG (Ronald G Minnich) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: <30818@super.ORG> Date: 6 Aug 90 17:14:58 GMT References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <1990Aug1.171148.22119@zoo.toronto.edu> <1944@ux.acs.umn.edu> Sender: news@super.ORG Reply-To: rminnich@super.UUCP (Ronald G Minnich) Organization: Supercomputing Research Center, Bowie, Md. Lines: 46 In article mcgrath@paris.Berkeley.EDU (Roland McGrath) writes: >In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes: >> Currently the methods of structure member ordering, and packing >> specifications are easy enough to figure out that you can easily write a >> structure that models some hardware/OS data structure rather well. Boy, talk about a bad case of deja vu. A long time ago, there was an interesting little systems programming language. It allowed you to define data structures and lay them out exactly as they would have to be layed out in memory. If the machine you were on could not handle odd addresses it was your responsibility to pad the structures yourself. As it happened it was just terrific for writing OS code on minicomputers and things like that. I assume you all can guess the name of this language. We used to make fun of Pascal because you could define a structure in Pascal but never really be sure of how it got laid out, unless of course you used "packed" and kind of knew how the compiler laid things out and how big the compiler assumed certain scalar types were and so on. Sound familiar? >If you want to have a `struct' that corresponds to some hardware thing or >whatever, and you know enough about the C compiler's padding conventions to do >this, then write it inside `extern "C"' in C++. This still doesn't guarantee >you a damn thing as far as the standards are concerned. >"We can't allow A in the standard because it makes it more difficult to do >nonstandard, unportable hack B (which is not guaranteed by the standard to >work, but which probably will most days of the week)" does not sound to me like >a reasonable argument. So, if i read this right, C (and hence its descendant, C++) has moved so far from its origins as a systems programming language that it is now useless for some things it used to be very good for, e.g. writing device drivers. Not only that, but that one particular use is being called a nonstandard, unportable hack, whereas at one time (I know, maybe too long ago) that was cited as a "case in point" for the power of the language. This is progress? I think that if C++ and/or C could somehow resolve this problem of exact bit-by-bit specification of a structure, a problem which actually has been solved many other times in other languages, that would enhance its usefulness. And it would sure be nice if whatever comes out does not have magic numbers like 16 or 32 hidden in it. -- 1987: We set standards, not Them. Your standard windowing system is NeUWS. 1989: We set standards, not Them. You can have X, but the UI is OpenLock. 1990: Why are you buying all those workstations from Them running Motif?