Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!uunet!pyrdc!netxcom!ewiles
From: ewiles@netxcom.DHL.COM (Edwin Wiles)
Newsgroups: comp.std.c++
Subject: Re: "packed" objects
Message-ID: <6785@netxcom.DHL.COM>
Date: 31 Jul 90 17:55:14 GMT
References: <56159@microsoft.UUCP> <56165@microsoft.UUCP>
Organization: NetExpress Communications Inc,. Vienna, VA.
Lines: 55

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>Proposed:
>
>We need a way to "pack" objects over inheritence boundaries, and possibly
>between labeled fields of a declaration.  I do not propose here exactly
>what the "right" way to do this is.

[edited for brevity]

>Possible full or partial "solutions" to this problem include:
>
>* Throw out the current C++ restrictions on field ordering entirely.  What
>does it buy us anyway?  Use 'extern "C"' where an object needs backwards
>compatibility to "C" packing order.
>* Require current field ordering restrictions be maintained on things declared
>"struct", but removed restrictions on anything declared "class."

Let's see if I understand what you're proposing in the above two options.

I get the idea that what you want is to have the compiler be able to
assemble the fields in the classes in any order, rather than strictly
in the order in which they were defined.  Which *would* allow you to
pack bit fields together in the way you want, however....

I would argue against both of the above as a 'default' for the following
reasons:

	A) You would not be guaranteed that a data file written by a given
	program on one machine, would be readable by the same program compiled
	on a different machine under a different implementation of C++.
	(Assuming that hardware and byte ordering are the same, the order
	of structure/class elements wouldn't necessarily be the same.)

	B) Certain C++ languages (Lattice C++ for the Amiga for one) make
	extensive use of C++ structures/classes to hide the cruft of working
	with the system libraries.  Surely a desireable end.  However, the
	system libraries depend on a specific order of elements within a
	structure and would likely break under either of the above.

>* 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....

This would be more acceptable, as it leaves it as an option that the programmer
can use if appropriate, but doesn't force the issue.  However, it could still
have the problems shown above, and should therefore NOT be used where
portability is important.  If the structure/class is purely internal, never
appearing outside of the program in question, then it's acceptable.

At least not until the order and method of packing items is agreed upon
by the C++ industry, and preferably by the C compiler writers as well!

[disclaimer: this posting respresents the opinions of an individual C++ user]