Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!microsoft!jimad
From: jimad@microsoft.UUCP (Jim ADCOCK)
Newsgroups: comp.std.c++
Subject: Re: "packed" objects
Message-ID: <56637@microsoft.UUCP>
Date: 16 Aug 90 18:53:53 GMT
References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <1030@lupine.NCD.COM>
Reply-To: jimad@microsoft.UUCP (Jim ADCOCK)
Organization: Microsoft Corp., Redmond WA
Lines: 51

In article <1030@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>>Use 'extern "C"' where an object needs backwards
>>compatibility to "C" packing order.
>
>Huh?

Just what it says.  Using 'extern "C"' around a class or structure 
definition will give you a structure that is compatible with your
C compiler [from the same vendor 1/2 :-]  Using 'extern "Pascal"' around
a class or structure definition will give you a structure that is
compatible with your Pascal compiler [from the same vendor 1/4 :-]
Otherwise, you'd not be gauranteed any backwards compatability between
the layout of a C++ class/structure, and a C or Pascal structure.

>>* Require current field ordering restrictions be maintained on things declared
>>"struct", but removed restrictions on anything declared "class."
>
>Bad idea.

I don't disagree, but state why you don't like this one so the rest of
us can follow your logic.

>>* Introduce an explicit keyword "packed" or similar.  Declaring a base class
>>"packed" turns off field ordering restrictions in that class and its 
>>derivatives, as well as representing a directive to the compiler that small
>>size is to be preferred to fast access.  Possibly vtable ptrs could also 
>>be replaced with smaller type tags in such classes....
>
>Since the issue involves the boundary between a derived class and exactly
>one of its base classes, I suggest that perhaps "packed" should be a way
>of doing inheritance, e.g.:
>
>	class doe : public rea, packed public me { ... };
>
>would specify that the earliest field of `doe' should get packed up against
>the latest field of `me'.

The problem is, the proposal intends not only to address the issue of
"packing up against" a base class, but also the possibility of 
"packing into" a base class.  Since "packing into" a base class might
require an explicit awareness in the base class not to mess with 
unused fields, the packed'ness needs to be declared in the base class.
Two choices then might be to make packed'ness a inherited attribute,
or to have to be redeclared in subsequent derived classes.  Seems to me
once a superclass has a packed attribute, the die has been cast,
any backwards compatibility is lost, and subsequent derived classes
should automatically follow their base class's packed or unpacked'ness.
Likewise, in MI having one base class packed would be enough to make
derived classes "packed."  "Packed" in this sense just means that C
packing rules are not necessarily being followed.