Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!aplcen!samsung!umich!umeecs!msi-s0.msi.umn.edu!cs.umn.edu!ux.acs!hopper
From: hopper@ux.acs.umn.edu (hopper)
Newsgroups: comp.std.c++
Subject: Re: "packed" objects
Message-ID: <1953@ux.acs.umn.edu>
Date: 3 Aug 90 23:11:37 GMT
References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <1990Aug1.171148.22119@zoo.toronto.edu> <1944@ux.acs.umn.edu> <MCGRATH.90Aug3011039@paris.Berkeley.EDU>
Reply-To: hopper@ux.acs.umn.edu (Eric Hopper)
Organization: Omnifarious Software
Lines: 48

In article <MCGRATH.90Aug3011039@paris.Berkeley.EDU> mcgrath@paris.Berkeley.EDU (Roland McGrath) writes:
>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.
                     .
                     .
                     .
>   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.

	I think you've missed my point. One of the nicer things about C, and
C++ is the ability to write anything you darn well please, whether it
accesses memory mapped I/O directly, models a complicated hardware
structure, or what have you. If you suddenly make the ordering of you
structures & classes hard to figure out, such things will no longer be very
easy.

	I like the idea of a compiler being able to re-order my data
structures to make them more efficient, but having it do this all the time
could get to be VERY annoying if I'm trying to do something with the things
mentioned above. I want C++ to remain a language that one can write an OS
in.

Have fun,
UUCP: rutgers!umn-cs!ux.acs.umn.edu!hopper   (Eric Hopper)
     __                    /)                       /**********************/
    / ')                  //                         * I went insane to   *
   /  / ______  ____  o  //  __.  __  o ____. . _    * preserve my sanity *
  (__/ / / / <_/ / <_<__//__(_/|_/ (_<_(_) (_/_/_)_  * for later.         *
Internet:              />                            * -- Ford Prefect    *
hopper@ux.acs.umn.edu </  #include <disclaimer.h>   /**********************/