Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: Packing, Ordering, and Rearranging
Message-ID: <57987@microsoft.UUCP>
Date: 4 Oct 90 21:29:00 GMT
References: <1407@lupine.NCD.COM| <2218@ux.acs.umn.edu> <57467@microsoft.UUCP> <1990Sep21.130531.7437@zorch.SF-Bay.ORG> <57650@microsoft.UUCP> <57681@microsoft.UUCP> <2311@ux.acs.umn.edu> <57858@microsoft.UUCP> <2321@ux.acs.umn.edu>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 30

In article <2321@ux.acs.umn.edu| hopper@ux.acs.umn.edu (Eric Hopper) writes:
|	I can't see any references to that, the point is, is that you can do
|it. A given structure member IS garunteed to come after a previous strcture
|member, and most compiler vendors tell you the sizes of their various
|fields, and their padding rules. Wala! You can declare structures that will
|be packed in a particular fashion.
|
|	The argument that this is non-portable is silly. Of course it isn't
|portable. There are occaisionally VERY good reasons to do it though, and the
|issue that doing so isn't portable becomes moot. If strange structure
|packing were stuck in C++ it may not be possible anymore to do these
|neccesary, non-portable things.

Not to worry, I don't believe any C++ compiler is going to keep you from
doing these things.  Clearly, C++ compilers over the short term will be
highly motivated to remain closely compatible to earlier C compilers.
The issue in my mind is should the C++ language standards explicitly 
prevent any compiler from doing anything else *but* be strictly "C"-like
forever more?

As before, to pad the way you want, you'll need to understand a particular
compilers paddings rules to be able to trick the packing the way you 
want.  And, when doing virtual functions, virtual bases, multiple inheritence,
etc, you'll also have to understand how a particular compiler organizes those
things, and where and how they hide the 'nasty bits' like vtable ptrs,
vbase accessing etc.

My position is to let the language standard specify the language, and let
marketing forces [aka "customers"] specify the compiler implementations 
-- which may need to evolve as we learn more about object oriented programming.