Re: "packed" objects (Oops! Forgot something!)

[Greg Stein <gstein@xxxxxxxxxx>]

In article <6786@xxxxxxxxxxxxxxx> ewiles@xxxxxxxxxxxxxxx (Edwin Wiles) writes:
> In article <56165@xxxxxxxxxxxxxx> jimad@xxxxxxxxxxxxxx (Jim ADCOCK) writes:
> >* 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....
> 
> Any derivative that uses a 'packed' class, but is not itself packed should
> be flagged in the compiler with at least a warning message.  The user of the
> base class might not realize that it was packed!  In fact, you might declare
> such useage an error and REQUIRE the user to explicitly mark the new class
> as packed.
> 
> [disclaimer: this posting respresents the opinions of an individual C++ user]

Nope.  The derivative class would tack all of its fields onto the end
rather than mixing them in.  You would end up with a structure that is
initially packed with unpacked stuff at the end.  This should be quite
allowable.

Where you will get into trouble is if you try to derive a packed class
from an unpacked class.  This should definitely be an error.  This is
cuz you don't want the subclass to try packing itself into the parent
class.

---

That was an argument from a purely theoretical standpoint.  I think
packed classes are dumb.  You should be able to guarantee the ordering
somewhat.  You would have some really nasty rules to define for things
like structures within the class, bit fields that are to be packed as
a unit rather than mixed in, etc.

The original poster said that these would be good for avoiding things
like defining funny bit fields that are shared by subclasses and such.
I would state that a correct implementation of a shared bit field
array can be accomplished quite nicely and straightforward through a
combination of inline methods for accessing the bit fields.  The only
problem you may hit is if you need to add a bit field to a superclass
when some subclasses have already used some (i.e. class a uses bits 0
to 2 and subclass b uses 3 and 4; it might not be trivial to reserve
an additional bit for a).  I think even this can be overcome through
the correct use of inline functions and a proper protocol for
declaring how many bits a particular class uses.

[ I can supply a rough sketch of the code necessary if somebody needs
  it -- I'm just too lazy to do it and I don't know C++ off the top of
  my head... ]

--
Greg Stein	-- This posting bears no relation to my employer
Arpa: gstein%oracle.uucp@xxxxxxxxx
UUCP: ..!{uunet,apple}!oracle!gstein