Path: utzoo!utgpu!news-server.csri.toronto.edu!clyde.concordia.ca!mcgill-vision!snorkelwacker!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wuarchive!uunet!xstor!iverson
From: iverson@xstor.UUCP (Tim Iverson)
Newsgroups: comp.std.c++
Subject: Packing, Ordering, and Rearranging
Message-ID: <195@xstor.UUCP>
Date: 17 Aug 90 20:12:26 GMT
References: <56159@microsoft.UUCP> <56165@microsoft.UUCP> <1030@lupine.NCD.COM> <56637@microsoft.UUCP>
Reply-To: iverson@xstor.UUCP (Tim Iverson)
Organization: Storage Dimensions, Inc.
Lines: 43


It seems that the discussion about packing currently needs some refinement
in the area of semantics.  I've always used 'packed' to mean that there is
no padding inserted into a struct (i.e. it's a WYSIWIG struct).  And,
'ordering' has always meant bit placement within a byte and byte placement
within a word.  So what seems to be under discussion here is really a
combination of packing and rearranging fields within a struct.

Both packing and ordering are highly desirable for the simple reason that
as the language (C/C++) stands now, it cannot deal *transparently* with the
real world.  This is due solely to the lack of rigor in the specification
for the definition of a struct - the compiler is allowed too much latitude
in the physical layout of a struct.

Your common intelligent programmable electric toaster device often (always?)
requires strange and arcane packing and bit fiddling to get data into and
out of the controlling interface.  Almost invariably, this results in
several routines to read in the data and stuff it into a structure, rather
than just reading it into the structure.  The same is true for many programs
that must import or export data.

If the language had constructs for specifying such things as packing and
ordering (bit, word, etc.), it could deal transparently with structures
created outside of its own venue and should result in code that is
both cleaner and more portable.

As far as the format of the extension goes, it should be a pure extension
and should not give new meaning to keywords currently in use.  If you
overload the current keywords, it is virtually guaranteed to break programs
that work fine as they are now.  This means that applying a special meaning
to 'extern' is a very bad idea.  It also means that default behavior must
conform to the current default - so any 'packing', 'ordering', or
'rearranging' extensions must be used explicitly in each place that they
are desired.

I admit that these thoughts are rather general, but hopefully they will
spawn another more concrete discussion. If not, I could always fire up the
old blow torch and start a jihad:  maybe something like, oh, say "cobol is
inherently better than C ..." :->.


- Tim Iverson
  uunet!xstor!iverson