Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!sdd.hp.com!decwrl!ucbvax!pasteur!paris.Berkeley.EDU!mcgrath From: mcgrath@paris.Berkeley.EDU (Roland McGrath) Newsgroups: comp.std.c++ Subject: Re: "packed" objects Message-ID: Date: 3 Aug 90 08:10:39 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@pasteur.Berkeley.EDU Organization: Hackers Anonymous International, Ltd., Inc. (Applications welcome) Lines: 44 In-reply-to: hopper@ux.acs.umn.edu's message of 2 Aug 90 23:23:53 GMT In article <1944@ux.acs.umn.edu> hopper@ux.acs.umn.edu (hopper) writes: One of the nicer things in C, (and C++) is to be able to create machine specific data sructures that correspond to some area in memory. (i.e. bit-fields and such). I agree that writing machine specific code is generally undesirable, sometimes it is necessary. 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. If packing of bit-fields, and structure members became a standard, unavoidable thing, this would no longer be easy to do. In other words, you would no longer be able to write an OS in C++. We are talking here about Standard C++. In Standard C, you can't necessarily have a `struct' that corresponds to a hardware layout, because there may be padding (and the standard leaves it completely up to the implementation, except that there can be no padding before the first member). 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. You must remember that we are talking about the standard for C++. I propose simply that the standard make no restrictions about structure member order (outside of `extern "C"', since inside `extern "C"' the restrictions of standard C apply). That member reordering makes various implementation details difficult (like that base classes must deal with derived classes' members possibly being in between the base class's members) is none of the standard's bloody business. It's an implementation problem. If all these problems are as insurmountable as you seem to think, then no implementor will overcome them, and no implementation will reorder structure members. I don't know how to implement reordering correctly either, but I'm more than willing to concede that some C++ implementor out there is more clever than I, and see no reason to prohibit someone else from doing something I can't figure out how to do. -- Roland McGrath Free Software Foundation, Inc. roland@ai.mit.edu, uunet!ai.mit.edu!roland