In article <GSTEIN.90Jul31194438@goober.oracle.com>, gstein@oracle.com
(Greg Stein) writes:
> 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.

If a packed is derived from a non-packed, the packing should not intrude
into the non-packed base class.  This introduces no compilation problems.

This whole idea is nuts. It's clear that C++ really needs one more
feature that severely restricts the ability to do derivation.

Jon

In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (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]

In article <6786@netxcom.DHL.COM> ewiles@netxcom.DHL.COM (Edwin Wiles) writes:
> In article <56165@microsoft.UUCP> jimad@microsoft.UUCP (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@apple.com
UUCP: ..!{uunet,apple}!oracle!gstein

The only arguments I have heard against arbitrary reordering of structures are
that it is incompatible with C, and that it makes writing structures to files
less portable.

Being incompatible with C is not something I consider a valid reason for not
doing something.  That's why we have `extern "C"'.  A structure declared within
`extern "C"' would, of course, obey C's conventions and not get reordered.

Writing structures to files as they appear in memory is not portable anyway.
Even given the same machine (and thus the same sizes for the basic types and
the same byte and word orders), different compilers (or even different compiler
options) may use different padding in structures.

Are there any other arguments against allowing arbitrary reordering of
structures?
--
 Roland McGrath
 Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MCGRATH.90Aug1122802@helen.Berkeley.EDU> mcgrath@helen.Berkeley.EDU (Roland McGrath) writes:
>Are there any other arguments against allowing arbitrary reordering of
>structures?

Yes, I want to have a data structure with several different kinds of
nodes.  Each node contains common data that may be manipulated by
general purpose routines that do not need understand the rest of the
data in each node.  I want to be sure that the layout of each node
begins the same way.  I don't want to use a union since the nodes range
in size from a few bytes to hundreds of bytes (the larger nodes being rare).

--
Scott Amspoker
Basis International, Albuquerque, NM
(505) 345-5232
unmvax.cs.unm.edu!bbx!bbxsda!scott

In article <MCGRATH.90Aug1122802@helen.Berkeley.EDU>
mcgrath@helen.Berkeley.EDU (Roland McGrath) writes:

| The only arguments I have heard against arbitrary reordering of structures are
| that it is incompatible with C, and that it makes writing structures to files
| less portable.
|
| Being incompatible with C is not something I consider a valid reason for not
| doing something.  That's why we have `extern "C"'.  A structure declared within
| `extern "C"' would, of course, obey C's conventions and not get reordered.
|
| Writing structures to files as they appear in memory is not portable anyway.
| Even given the same machine (and thus the same sizes for the basic types and
| the same byte and word orders), different compilers (or even different compiler
| options) may use different padding in structures.
|
| Are there any other arguments against allowing arbitrary reordering of
| structures?

Hmm, don't you care about compatibility with things like system calls?
I imagine the grief people would get if the stat structure got
rearranged because some OS jock added a byte field at the end of the
structure?  Yes, extern "C" can be used, but it just means that there
are even more things to worry about getting right.

Also, it would seem to me that reordering things across class
boundaries is a really bad idea -- then subclassing and virtual
functions would have no chance of working.
--
Michael Meissner email: meissner@osf.org  phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA

Do apple growers tell their kids money doesn't grow on bushes?

In article <MEISSNER.90Aug1191316@osf.osf.org> meissner@osf.org (Michael Meissner) writes:

   Hmm, don't you care about compatibility with things like system calls?
   I imagine the grief people would get if the stat structure got
   rearranged because some OS jock added a byte field at the end of the
   structure?  Yes, extern "C" can be used, but it just means that there
   are even more things to worry about getting right.

If you don't declare the `stat' function inside `extern "C"', it won't
necessarily work right anyway.  Using:

extern "C"
{
#include <sys/stat.h>
}

seems entirely reasonable to me.

   Also, it would seem to me that reordering things across class
   boundaries is a really bad idea -- then subclassing and virtual
   functions would have no chance of working.

If it is not feasible to reorder members across class boundaries and still do
subclassing and virtual functions right then noone will try to do it in their
implementation.  That doesn't mean the standard should prevent people from
trying if they want to.
--
 Roland McGrath
 Free Software Foundation, Inc.
roland@ai.mit.edu, uunet!ai.mit.edu!roland

In article <MEISSNER.90Aug1191316@osf.osf.org> meissner@osf.org (Michael Meissner) writes:
>I imagine the grief people would get if the stat structure got
>rearranged because some OS jock added a byte field at the end of the
>structure?  Yes, extern "C" can be used, but it just means that there
>are even more things to worry about getting right.

In the case of system calls, system header files are charged with getting
this right for you; there is no reason for you to be defining your own
version of the stat structure.  OS jocks *always* have to worry about
compatibility when they change interfaces.
--
The 486 is to a modern CPU as a Jules  | Henry Spencer at U of Toronto Zoology
Verne reprint is to a modern SF novel. |  henry@zoo.toronto.edu   utzoo!henry