Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!wuarchive!uunet!lupine!rfg
From: rfg@NCD.COM (Ron Guilmette)
Newsgroups: comp.std.c++
Subject: Re: "packed" objects
Message-ID: <1227@lupine.NCD.COM>
Date: 18 Aug 90 06:57:44 GMT
References: <56165@microsoft.UUCP> <1030@lupine.NCD.COM> <56637@microsoft.UUCP>
Organization: Network Computing Devices, Inc., Mt. View, CA
Lines: 58

In article <56637@microsoft.UUCP> jimad@microsoft.UUCP (Jim ADCOCK) writes:
>In article <1030@lupine.NCD.COM> rfg@NCD.COM (Ron Guilmette) writes:
>
>>>* 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.

As I have stated, I am adamantly opposed to anything which allows a C++
compiler to mess with the layout of *any* of *my* data structures (whether
they be structs or classes or unions) unless of course such a `feature'
(and I use the term loosely) were provided as a kind of upward compatible
extension via #pragma's or special compiler options.  In other words,
I would prefer it if all compilers were required to accept (as the primary
default) the assumption that I know what I'm doing when I specify an
ordering for my fields.

Believe it or not, in practice I find that I *do* know what I'm doing
when I write a struct type definition (and likewise a class type definition).
As a matter of fact, I often spend a good deal of time thinking about how
to do such things so that I get "efficient space usage".

I certainly know what I'm doing (better than *any* compiler ever will) when
I'm specifying data structures that *must* be layed out a certain way (e.g.
because they reflect a memory mapped device's layout or because the layout
is otherwise dictated by external constraints such as existing formats in
disk files or over communications media).

Just because some people feel that some mythical future compiler will be able
to layout data structures better than they themselves can, this is no reason
to penalize the rest of us (and provide us with *no* recourse) when we want
or need to have precise control of the layout of our data structures.

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

I consider these to be two different problems.  Packing fields within a
struct (or class) is something I can do perfectly well right now with
C, thank you.  If C++ would just stick to its roots in this respect I
would have all of the control that I need to take care of packing the
fields within a struct (or class) myself.

The problem of packing across inheritance boundaries is a different
matter however.  This is an entirely new problem in C++, and (I feel)
it needs to have a proper solution so that the programmer can (once
again) be in complete control over data structure layout.  (Right now,
he's not because the current de-facto standard doesn't mandate anything
in particular about the packing, or lack thereof, which occurs at these
boundaries.)
-- 

// Ron Guilmette  -  C++ Entomologist
// Internet: rfg@ncd.com      uucp: ...uunet!lupine!rfg
// Motto:  If it sticks, force it.  If it breaks, it needed replacing anyway.