Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  James Kanze wrote:
|>  >
|>  > Valentin Bonnard <bonnardv@pratique.fr> writes:
|>  >
|>  > |>  > This question is inspired by the following C practice:
|>  > |>  >
|>  > |>  > struct msghdr { // POD structure for an "over the wire"
|>  > |>  >       // message header
|>  > |>  >   ...
|>  > |>  > };
|>  > |>  >
|>  > |>  > struct someTypeOfMessage {
|>  > |>  >         struct msghdr  hdr;
|>  > |>  >         ...
|>  > |>  > };
|>  > |>  >
|>  > |>  > In C (and C++), I know I could
|>  > |>
|>  > |>  You could but you can't: how can you send some type and receive
|>  > |>  annother one, except with a reinterpret_cast (which can be
|>  > |>  return 0, as James Kanze said) ?
|>  >
|>  > Woah...
|>  >
|>  > First, what I said wasn't correct, as has already been pointed out.
|>
|>  Can you cite an extract which _really_ prove that
|>  assert (reinterpret_cast<void*> (anything) as to work ?

5.2.10/7: "A pointer to an object can be explicitly converted to a
pointer to an object of different type.11) Except that converting an
rvalue of type "pointer to T1" to the type "pointer to T2" (where T1 and
T2 are object types and where the alignment requirements of T2 are no
stricter than those of T1) and back to its original type yields the
original pointer value, the result of such a pointer conversion is
unspecified."

A void pointer cannot have any alignment restrictions.  (Actually, you
may have a point here.  It is fairly easy to argue that the alignment
restrictions for a T* cannot be greater than sizeof( T ), but where does
that get us for void*?)

If memory serves me right, the C standard guarantees casting to void*
and back, rather than talking about alignment restrictions.  (But I
could be wrong about this.  My copy of the C standard isn't here.)  I
feel certain that it is the intent of C++ to offer the same guarantee; I
interpret the above passage as meaning that they want to offer more.  Is
it just possible that in attempting to offer more, they accidentally
eliminated the one guarantee already there?

|>  I couldn't find any (no implementation will fail this test,
|>  but we are in comp.STD.c++, aren't we ?).
|>
|>  > (The draft sets more constraints on reinterpret_cast than I thought.)
|>  >
|>  > More to the point, even what I said didn't (or at least, wasn't meant
|>  > to) cover this case.  This is definitly legal, and always had been; it
|>  > is explicitly authorized in the C standard.
|>
|>  My comment was 100% about C++ (I could have made that more clear).

I am supposing that C++ does not break with C in this area, at least not
intentionally.

I am curious about the exact relationship between the two standards.
I've heard somewhere that the C standard is included in the C++ standard
"by reference"; this is certainly the case with regards to the C
standard libraries.  Could someone confirm (or deny) that this is the
case in general.  In such a case, one could argue that if the C standard
guarantees something, and the issue isn't addressed in the C++ standard,
then the C++ standard also guarantees it.

|>  > It's one of a limited
|>  > number of special cases, like casting from void* to the type initially
|>  > used to initialize it, which are well defined.
|>
|>  Well, I understand that the poster wanted to write:
|>
|>  struct msghdr { // POD structure for an "over the wire" message header
|>  .... };
|>
|>  void foo (msghdr);
|>
|>  struct someTypeOfMessage {
|>          struct msghdr  hdr;
|>  };
|>
|>  someTypeOfMessage message;
|>
|>  foo (reinterpret_cast<msghdr&> (message));
|>
|>  The value is implementation defined. The effects of converting
|>  to a rvalue are IMO undefined (basically what's John E. Potter
|>  wrote in the article suitable_cast).

No.  For obvious reasons, the alignment requirements of
"someTypeOfMessage" must be at least as great as those for "msghdr".

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

cano@loc201.tandem.com (cano_jonathan) writes:

>I've been looking over the "april working paper" of the C++ standard
>(http://www-leland.stanford.edu/~iburrell/cpp/std.html) and I can't
>figure out the answer to the following question:
>
>given:
>
>class base { // a POD class
> int a;
> ...
>};
>
>class derived : public base { //  a POD class

Not possible.  A POD may not have base classes.

DWP 3.9[basic.types]/10: "scalar types, POD-structs, ... and ...
are collectively called POD types".
DWP 9[class]/4: "a POD-struct is an aggregate ...".
DWP 8.5.1[decl.init.aggr]/1: "an aggregate is an array or class ...
with no base classes".

>P.S. is there a newer version of the C++_draft_standard than the
>28-April-1995 paper that I am browsing?

Yes.  See <http://www.maths.warwick.ac.uk/c++/pub/> or
<http://www.setech.com/x3.html> for the latest publically available draft.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

cano@loc201.tandem.com (cano_jonathan) writes:

|>  I've been looking over the "april working paper" of the C++ standard
|>  (http://www-leland.stanford.edu/~iburrell/cpp/std.html) and I can't
|>  figure out the answer to the following question:
|>
|>  given:
|>
|>  class base { // a POD class
|>   int a;
|>   ...
|>  };
|>
|>  class derived : public base { //  a POD class
|>      char c;
|>   ...
|>  };
|>
|>  class composed {  // a POD class
|>   base  b;
|>      char  c;
|>
|>      ...
|>  };
|>
|>  Will the memory layout of `derived' objects be the same as the memory
|>  layout of `composed' objects, assuming all the classes above are POD
|>  classes?

Undefined.  Class derived is not a POD: from chapter 9, paragraph 4: "A
POD-struct is an aggregate class that has no non-static data members of
type pointer to member, non-POD-struct, non-POD-union (or array of such
types) or reference, and has no user-defined copy assignment operator
and no user-defined destructor."  And in 8.5.1 (paragraph 1): "An
aggregate is an array or a class with no user-declared constructors, no
private or protected non-static data members, no base classes, and no
virtual functions."

A POD must be an agregate, and an agregate cannot have a base class.
Thus, "derived" is not a POD, and (almost) all bets concerning layout
are off.

Note that it IS guaranteed that in composed, the address of the complete
object composed, suitably cast, is equal to the address of its first
member, base.  But this guarantee is *only* given for PODS's.

I've cut the rest, since it seems entirely based on the
misinterpretation that "derived" is a POD.  (I'll admit that when I
first looked at the definition of POD in chapter 9, I was fooled too.
Until I looked at the Note, and followed the reference.)

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

cano_jonathan wrote:=20
> I can't
> figure out the answer to the following question:
>=20
> given:
>=20
> class base {    // a POD class
>         int a;
>         ...
> };
>=20
> class derived : public base {   //  a POD class

No, a normal class (since it has a base class)

>     char c;
>         ...
> };
>=20
> class composed {        // a POD class

Normal class (contains derived).

>         base  b;
>     char  c;
>=20
>     ...
> };
>=20
> Will the memory layout of `derived' objects be the same as the memory
> layout of `composed' objects, assuming all the classes above are POD
> classes?  How about if only `base' is a POD class?

This is not guarantied (but often/always the case in practice).

> This question is inspired by the following C practice:
>=20
> struct msghdr { // POD structure for an "over the wire" message header
>   ...
> };
>=20
> struct someTypeOfMessage {
>         struct msghdr  hdr;
>         ...
> };
>=20
> In C (and C++), I know I could=20

You could but you can't: how can you send some type and receive=20
annother one, except with a reinterpret_cast (which can be=20
return 0, as James Kanze said) ?

> send a `someTypeOfMessage' struct over
> the wire and the recipient could get at the `msghdr' by treating a
> pointer to the who `someTypeOfMessage' struct as a pointer to a
> `msghdr' struct.
>=20
> - From what I've read in the april working paper, I should definitely b=
e
> able to do the same thing with `class composed' objects and `class
> base objects' but I can't seem to find any mention of where *base
> class data* is placed relative to *member data*.

This (IMO) is not mentionned because (in particular) there=20
is no guaranty if you use MI.

> With the compilers that I've tested, the layout of "base/derived
> class" example above is that a pointer to a "class derived" object
> points to the first data member of "class base" and not the first data
> member of "class derived" (i.e. derived.c).  I find this confusing
> give the draft standards statement:
>=20
>    [ section 9.2 ]
>=20
> 16A  pointer  to  a POD-struct object, suitably converted, points to it=
s
>   initial member (or if that member is a bit-field, then to the unit  i=
n
>   which  it  resides)  and  vice versa.  [Note: There might therefore b=
e
>   unnamed padding within a POD-struct object, but not at its  beginning=
,
>   as necessary to achieve appropriate alignment.  ]
>=20
> Is this seeming incongruity due to my misunderstanding of the passage
> above (perhaps my notion of 'initial member' is wrong...)=20

Yes and no. A POD simply doesn't have base classes.

The DWP seem consistant in this area (it's wonderfull, isn't it ?).

> or the fact
> that the compilers I've tested aren't yet implementing this
> functionality correctly?

They wouldn't change the layout of the classes just to follow the=20
standard, would they ;-) ?

--=20

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)

----------------------------------------------------------------------

Useless .sig follow; remove it if you want, but I have to put=20
sometime to satisfy my newserver.


 |     /    +---+
 |    /     |    \
 |   /      |     |
 |  /       +-----+
=A0| /        |     |
 |/         |    /
 |    .     +---/    .


--=20

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

In article fsf@prism.loc201.tandem.com, cano@loc201.tandem.com (cano_jonathan) writes:
>
>I've been looking over the "april working paper" of the C++ standard
>(http://www-leland.stanford.edu/~iburrell/cpp/std.html) and I can't
>figure out the answer to the following question:

First, don't use the April 1995 draft any more. Use the December 1996
draft instead. It is available at
 http: //www.setech.com/x3.html
        http://www.maths.warwick.ac.uk/c++/pub/


>given:
>
>class base { // a POD class
> int a;
> ...
>};
>
>class derived : public base { //  a POD class
>    char c;
> ...
>};
>
>class composed {  // a POD class
> base  b;
>    char  c;
>
>    ...
>};
>
>Will the memory layout of `derived' objects be the same as the memory
>layout of `composed' objects, assuming all the classes above are POD
>classes?

The "composed" class should have the same layout as with a compatible
C compiler, since the POD rules are intended to match the C rules
for structs and unions.

A POD class cannot have any base classes, so "derived" is not a POD.
It is likely with most implementations that derived and composed
will have the same layout, but you cannot depend on it.

See section 9 "Classes" and 8.5.1 "Aggregates".


>... I can't seem to find any mention of where *base
>class data* is placed relative to *member data*.

That is because the layout is unspecified. The implementation can
do (almost) anything it wants, and can lay out two similar-looking
classes differently if it wants to.

---
Steve Clamage, stephen.clamage@eng.sun.com
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

Valentin Bonnard <bonnardv@pratique.fr> writes:

|>  > This question is inspired by the following C practice:
|>  >
|>  > struct msghdr { // POD structure for an "over the wire" message header
|>  >   ...
|>  > };
|>  >
|>  > struct someTypeOfMessage {
|>  >         struct msghdr  hdr;
|>  >         ...
|>  > };
|>  >
|>  > In C (and C++), I know I could
|>
|>  You could but you can't: how can you send some type and receive
|>  annother one, except with a reinterpret_cast (which can be
|>  return 0, as James Kanze said) ?

Woah...

First, what I said wasn't correct, as has already been pointed out.
(The draft sets more constraints on reinterpret_cast than I thought.)

More to the point, even what I said didn't (or at least, wasn't meant
to) cover this case.  This is definitly legal, and always had been; it
is explicitly authorized in the C standard.  It's one of a limited
number of special cases, like casting from void* to the type initially
used to initialize it, which are well defined.

|>  > send a `someTypeOfMessage' struct over
|>  > the wire and the recipient could get at the `msghdr' by treating a
|>  > pointer to the who `someTypeOfMessage' struct as a pointer to a
|>  > `msghdr' struct.
|>  >
|>  > - From what I've read in the april working paper, I should definitely b=
|>  e
|>  > able to do the same thing with `class composed' objects and `class
|>  > base objects' but I can't seem to find any mention of where *base
|>  > class data* is placed relative to *member data*.
|>
|>  This (IMO) is not mentionned because (in particular) there
|>  is no guaranty if you use MI.

There is no guarantee even if you don't use MI.  The fact that a certain
number of compilers today happen to do it one way doesn't mean that it
is required.

--
James Kanze      home:     kanze@gabi-soft.fr        +33 (0)1 39 55 85 62
                 office:   kanze@vx.cit.alcatel.fr   +33 (0)1 69 63 14 54
GABI Software, Sarl., 22 rue Jacques-Lemercier, F-78000 Versailles France
     -- Conseils en informatique industrielle --
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

-----BEGIN PGP SIGNED MESSAGE-----

>>>>> "JK" == James Kanze <james-albert.kanze@vx.cit.alcatel.fr> writes:
In article <rf5g1yatzky.fsf@vx.cit.alcatel.fr> James Kanze
     <james-albert.kanze@vx.cit.alcatel.fr> writes:

cano@loc201.tandem.com (cano_jonathan) writes:
|>  I've been looking over the "april working paper" of the C++ standard
|>  (http://www-leland.stanford.edu/~iburrell/cpp/std.html) and I can't
|>  figure out the answer to the following question:
|>
|>  given:

 [ elided ]

|>
|>  Will the memory layout of `derived' objects be the same as the memory
|>  layout of `composed' objects, assuming all the classes above are POD
|>  classes?

 [ elided ]

JK> A POD must be an agregate, and an agregate cannot have a base
JK> class. Thus, "derived" is not a POD, and (almost) all bets
JK> concerning layout are off.

JK> Note that it IS guaranteed that in composed, the address of the
JK> complete object composed, suitably cast, is equal to the address
JK> of its first member, base.  But this guarantee is *only* given for
JK> PODS's.

JK> I've cut the rest, since it seems entirely based on the
JK> misinterpretation that "derived" is a POD.  (I'll admit that when
JK> I first looked at the definition of POD in chapter 9, I was fooled
JK> too. Until I looked at the Note, and followed the reference.)


OK -  I got the december working paper.

I finally discovered "section 10, paragraph 3" which says the location
of base class objects within their containing objects is unspecified.

I now (think I) understand what a POD class is.

To summarize the answer to my question: if I don't use inheritance and
I do stick with a structure that would be legal C and I will get
predictable memory layout (a la C) where a pointer to an object (when
suitably cast) points to its first data member (and vice versa).

Thanks to all who answered in the newsgroup and in email, you've been
very helpful!

Regards,
  --Jonathan Cano


-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMx82itg65GR/Kx7xAQFSBwP+KGAF8z+h3slA4kOFIfghnTinBD7wZp1d
FNTFZuXlU6jKZE/cAIHSCCNP7H7DeyF+X293pjhMcOPB5DLbqt4088FUmOzpFYLS
JwWlh08/rOjz861eck6zZ50tAO9cIeu0+mdjDbdzC0atLuUsPDj18FC7/z+vQ28o
Swy0VG2N94E=
=RF4M
-----END PGP SIGNATURE-----
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]

-----BEGIN PGP SIGNED MESSAGE-----

I've been looking over the "april working paper" of the C++ standard
(http://www-leland.stanford.edu/~iburrell/cpp/std.html) and I can't
figure out the answer to the following question:


given:

class base { // a POD class
 int a;
 ...
};

class derived : public base { //  a POD class
    char c;
 ...
};

class composed {  // a POD class
 base  b;
    char  c;

    ...
};

Will the memory layout of `derived' objects be the same as the memory
layout of `composed' objects, assuming all the classes above are POD
classes?  How about if only `base' is a POD class?

This question is inspired by the following C practice:

struct msghdr { // POD structure for an "over the wire" message header
  ...
};

struct someTypeOfMessage {
 struct msghdr  hdr;
 ...
};


In C (and C++), I know I could send a `someTypeOfMessage' struct over
the wire and the recipient could get at the `msghdr' by treating a
pointer to the who `someTypeOfMessage' struct as a pointer to a
`msghdr' struct.

- From what I've read in the april working paper, I should definitely be
able to do the same thing with `class composed' objects and `class
base objects' but I can't seem to find any mention of where *base
class data* is placed relative to *member data*.

With the compilers that I've tested, the layout of "base/derived
class" example above is that a pointer to a "class derived" object
points to the first data member of "class base" and not the first data
member of "class derived" (i.e. derived.c).  I find this confusing
give the draft standards statement:

   [ section 9.2 ]

16A  pointer  to  a POD-struct object, suitably converted, points to its
  initial member (or if that member is a bit-field, then to the unit  in
  which  it  resides)  and  vice versa.  [Note: There might therefore be
  unnamed padding within a POD-struct object, but not at its  beginning,
  as necessary to achieve appropriate alignment.  ]


Is this seeming incongruity due to my misunderstanding of the passage
above (perhaps my notion of 'initial member' is wrong...) or the fact
that the compilers I've tested aren't yet implementing this
functionality correctly?


References to the C++_draft_standard are encouraged.

Cheers,
  Jonathan

P.S. is there a newer version of the C++_draft_standard than the
28-April-1995 paper that I am browsing?



-----BEGIN PGP SIGNATURE-----
Version: 2.6.2
Comment: Processed by Mailcrypt 3.4, an Emacs/PGP interface

iQCVAwUBMxvBBtg65GR/Kx7xAQEsSgP7B5u0eUq2d2w1Nfvm3+e62vHeqKnrZsHX
vdP3Ot77+Otdor6pBq5lFpRqxHWWhWLV1LSBdpZTCu07sHZlnL4I9Z8uMmkD2c7B
iSHolNHx0HRJK3EgmYXz6l/YYIu6ziWPOAd7sb5N4ocBRdWsCW1QE61NJA2kzksx
IzYTfNALesA=
=YgU5
-----END PGP SIGNATURE-----
---
[ comp.std.c++ is moderated.  To submit articles: Try just posting with your
                newsreader.  If that fails, use mailto:std-c++@ncar.ucar.edu
  comp.std.c++ FAQ: http://reality.sgi.com/austern/std-c++/faq.html
  Moderation policy: http://reality.sgi.com/austern/std-c++/policy.html
  Comments? mailto:std-c++-request@ncar.ucar.edu
]

James Kanze wrote:
>
> Valentin Bonnard <bonnardv@pratique.fr> writes:
>
> |>  > This question is inspired by the following C practice:
> |>  >
> |>  > struct msghdr { // POD structure for an "over the wire" message header
> |>  >   ...
> |>  > };
> |>  >
> |>  > struct someTypeOfMessage {
> |>  >         struct msghdr  hdr;
> |>  >         ...
> |>  > };
> |>  >
> |>  > In C (and C++), I know I could
> |>
> |>  You could but you can't: how can you send some type and receive
> |>  annother one, except with a reinterpret_cast (which can be
> |>  return 0, as James Kanze said) ?
>
> Woah...
>
> First, what I said wasn't correct, as has already been pointed out.

Can you cite an extract which _really_ prove that
assert (reinterpret_cast<void*> (anything) as to work ?

I couldn't find any (no implementation will fail this test,
but we are in comp.STD.c++, aren't we ?).

> (The draft sets more constraints on reinterpret_cast than I thought.)
>
> More to the point, even what I said didn't (or at least, wasn't meant
> to) cover this case.  This is definitly legal, and always had been; it
> is explicitly authorized in the C standard.

My comment was 100% about C++ (I could have made that more clear).

> It's one of a limited
> number of special cases, like casting from void* to the type initially
> used to initialize it, which are well defined.

Well, I understand that the poster wanted to write:

struct msghdr { // POD structure for an "over the wire" message header
.... };

void foo (msghdr);

struct someTypeOfMessage {
        struct msghdr  hdr;
};

someTypeOfMessage message;

foo (reinterpret_cast<msghdr&> (message));

The value is implementation defined. The effects of converting
to a rvalue are IMO undefined (basically what's John E. Potter
wrote in the article suitable_cast).

--

Valentin Bonnard
mailto:bonnardv@pratique.fr
http://www.pratique.fr/~bonnardv (Informations sur le C++ en Francais)
---
[ comp.std.c++ is moderated.  To submit articles: try just posting with      ]
[ your news-reader.  If that fails, use mailto:std-c++@ncar.ucar.edu         ]
[ FAQ:      http://reality.sgi.com/employees/austern_mti/std-c++/faq.html    ]
[ Policy:   http://reality.sgi.com/employees/austern_mti/std-c++/policy.html ]
[ Comments? mailto:std-c++-request@ncar.ucar.edu                             ]