🚀 go-pugleaf

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