In article <9434910.19474@mulga.cs.mu.OZ.AU> fjh@munta.cs.mu.OZ.AU
(Fergus Henderson) writes:

> Newsgroups: comp.std.c++
> From: fjh@munta.cs.mu.OZ.AU (Fergus Henderson)
> Organization: Computer Science, University of Melbourne, Australia
>
> There is a notion of a "POD" (Plain Old Data Structure) which is
> defined in the working draft (8.5.1p10) as an aggregate which does not
> contain references or pointers-to-members.  (An aggregate can't have
> virtual functions, base classes, user-defined constructors, or
> private/protected members.)  In other words, a POD is just a C struct
> or union.  It is the intention of the committee to preserve
> C-compatibility for PODs, but not for any larger category.

I understand this was done to give the compiler more flexibility in
object layout (e.g., for compiling directly into CORBA), but it's too
bad that the list above includes base classes and user-defined
constructors.  There are very many inheritance hierarchies hidden
in ugly C structures that could be expressed nicely in C++ structures
with base structs (and, for convenience, user-defined constructors),
but would benefit from the C guarantee of flat structure layout.

Sigh.

Gruesse, Carsten

sjc@netcom.com (Steven Correll) writes:

>Clearly the committee has to walk a file line: on the one hand,
>demanding C compatibility in too many situations may rule out some useful
>C++ implementation schemes; on the other hand, it's useful to be assured
>that a simple struct will (provided the compiler-writers agree on their
>alignment rules) be interchangeable between languages. Could someone
>familiar with the current draft and the thinking of the committee tell me
>what to expect?

There is a notion of a "POD" (Plain Old Data Structure) which is
defined in the working draft (8.5.1p10) as an aggregate which does not
contain references or pointers-to-members.  (An aggregate can't have
virtual functions, base classes, user-defined constructors, or
private/protected members.)  In other words, a POD is just a C struct
or union.  It is the intention of the committee to preserve
C-compatibility for PODs, but not for any larger category.

--
Fergus Henderson - fjh@munta.cs.mu.oz.au

In article <sjcD0KAt1.AMG@netcom.com> sjc@netcom.com (Steven Correll) writes:
>ISO/ANSI C says (at least) these things about the layout of a struct:
>
> a. The address of the struct is equal to the address of
>   its first member.
> b. The addresses of successive members do not decrease.
> c. Padding may appear between members for alignment purposes.
>
>Clearly the committee has to walk a file line: on the one hand,
>demanding C compatibility in too many situations may rule out some useful
>C++ implementation schemes; on the other hand, it's useful to be assured
>that a simple struct will (provided the compiler-writers agree on their
>alignment rules) be interchangeable between languages. Could someone
>familiar with the current draft and the thinking of the committee tell me
>what to expect?

 There is a technical term PODS meaning

 "Plain Old Data Structure"

and any struct which is a PODS can be expected to be layed out
by a C/C++ compiler the same in both C and C++ -- although
there is no way to actually require that in a C++ Standard.

A PODS is a struct that, more or less, would be compilable
in C (No pointers to members, no references .. etc).
--
        JOHN (MAX) SKALLER,         INTERNET:maxtal@suphys.physics.su.oz.au
 Maxtal Pty Ltd,
        81A Glebe Point Rd, GLEBE   Mem: SA IT/9/22,SC22/WG21
        NSW 2037, AUSTRALIA     Phone: 61-2-566-2189

ISO/ANSI C says (at least) these things about the layout of a struct:

 a. The address of the struct is equal to the address of
   its first member.
 b. The addresses of successive members do not decrease.
 c. Padding may appear between members for alignment purposes.

The 1990 ARM [9.2] says that (b) is true for nonstatic data members
provided the list is not interrupted by an access specifier, and that
members may be separated not only by padding but also by space used
in managing virtual functions and virtual base classes. The commentary
in [11.1] says that requirement (b) "provides compatibility with existing
C code", but it doesn't seem to me that it is sufficient. In particular, I
can't find (a) in the ARM; in general, I can't find a specific statement
that an implementation isn't allowed to insert arbitrary housekeeping
information anywhere (even prior to the first member) within an aggregate
which doesn't need to manage virtual functions and virtual base classes.

Clearly the committee has to walk a file line: on the one hand,
demanding C compatibility in too many situations may rule out some useful
C++ implementation schemes; on the other hand, it's useful to be assured
that a simple struct will (provided the compiler-writers agree on their
alignment rules) be interchangeable between languages. Could someone
familiar with the current draft and the thinking of the committee tell me
what to expect?
--
Steven Correll == PO Box 66625, Scotts Valley, CA 95067 == sjc@netcom.com

In article AMG@netcom.com, sjc@netcom.com (Steven Correll) writes:
>
>Clearly the committee has to walk a file line: on the one hand,
>demanding C compatibility in too many situations may rule out some useful
>C++ implementation schemes; on the other hand, it's useful to be assured
>that a simple struct will (provided the compiler-writers agree on their
>alignment rules) be interchangeable between languages. Could someone
>familiar with the current draft and the thinking of the committee tell me
>what to expect?

The Working Paper defines enough extra stuff to ensure that a C struct
or union will have the same layout when compiled by a C++ compiler
(assuming that the compilers are otherwise compatible). I can't quote
all the stuff here, but it's in section 9.2 Class Members [class.mem],
with references to section 8.5.1 Aggregates [dcl.init.aggr], which in
turn refererences other sections.

---
Steve Clamage, stephen.clamage@eng.sun.com