Path: utzoo!attcan!uunet!samsung!usc!ucsd!ucbvax!galileo.berkeley.edu!jbuck
From: jbuck@galileo.berkeley.edu (Joe Buck)
Newsgroups: comp.std.c++
Subject: Re: "packed" objects
Message-ID: <37939@ucbvax.BERKELEY.EDU>
Date: 2 Aug 90 18:44:28 GMT
References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <6785@netxcom.DHL.COM> <6786@netxcom.DHL.COM> <GSTEIN.90Jul31194438@goober.oracle.com> <MCGRATH.90Aug1122802@helen.Berkeley.EDU> <MEISSNER.90Aug1191316@osf.osf.org> <MCGRATH.90Aug1231443@paris.Berkeley.EDU> <1
Sender: usenet@ucbvax.BERKELEY.EDU
Reply-To: jbuck@galileo.berkeley.edu (Joe Buck)
Lines: 35

In article <1990Aug2.142410.10541@watmath.waterloo.edu>,
gjditchfield@watmsg.uwaterloo.ca (Glen Ditchfield) writes:
|> Reordering does not have to go so far as to change the offsets of inherited
|> members.  The rule could be that new members can be placed in holes left by
|> padding in the superclass or in unused portions of storage units that
|> contain inherited bitfields.  I think this would do all the packing that
|> Jim Adcock originally wanted, without affecting current implementations of
|> inheritance.

Consider this example:

class Base {
	char c;
	int i;
}

Let's say there's a hole between c and i.

class Derived : public Base {
	char c2;
}

I take it you want to insert the c2 in the hole.

But does this mean that all methods of class Base have to make sure to preserve
the contents of holes, under all conditions, because the Base object may really
be a Derived object?  In this case that wouldn't be too hard, but what if c and
c2 were bitfields instead?  Think about compiler-generated assignment
operators.
Seems to me they'd get more complex.


--
Joe Buck
jbuck@galileo.berkeley.edu	 {uunet,ucbvax}!galileo.berkeley.edu!jbuck