In article <5Iqu4.1396$Wy3.3468@antares.worldonline.fr>,
  "Xavier Glattard" <xavier.glattard@netcourrier.com> wrote:
>
> Aleksey Gurtovoy <alexy@meta-comm.com> a    crit dans le message :
> 89avoi$bc$1@nnrp1.deja.com...
> > 10.5 [class.derived] paragraph 5 says:
> >
> > [Note: A base class subobject might have a layout (3.7) different
> > from the layout of a most derived object of the same type. ...]
>
> > But section 3.7 doesn't say anything about the class objects layout
> > or about 'layout' in general. Moreover, there are no definition of
> > the 'layout' at all. Was it considered a self-descriptive term?
> > There are a few definitions of the 'layout-compatible' types, but..
> > it's worth to define what a layout is about, before you talk about
> > layout-compatibility, right?
>
> > BTW, 3.9 [basic.types] paragraph 11 says:
> >
> > If two types T1 and T2 are the same type, then T1 and T2 are layout-
> > compatible types.
> >
> > As far as I understand, a base class subobject in a derived object
> > still has the same type as an ordinary object of that base
> > class :). So a compiler can't change the layout of base class
> > subobjects inside objects of derived classes - even if the
> > subobjects itself inherit from several virtual base classes...
>
> If two types have the same layout, then the followinf is safe :
>
> T1 t1;
> T2 t2;
>
> t1 = *((t1*)(void*)(&t2))
>
> But, the first note says that T1 and T2 _might_ have different layouts
> even if one is a base class of the other.
>

My points were

(1) there is a defect in 10.5.5, as it refers to a non-existing layout
definition

(2) the wording in 3.9.11 gives the guarantee that for following class
definitions

struct A {};
struct B {};
struct C: virtual A, virtual B {}
struct D: C {}

implementation will not change the layout of C subobject in D (e.g. the
order in which virtual bases are placed inside the subobject). It may
be important in some cases.

--
-Alexy


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Aleksey Gurtovoy <alexy@meta-comm.com> a    crit dans le message :
89h7pb$8l1$1@nnrp1.deja.com...
> In article <5Iqu4.1396$Wy3.3468@antares.worldonline.fr>,
>   "Xavier Glattard" <xavier.glattard@netcourrier.com> wrote:
> >
> > Aleksey Gurtovoy <alexy@meta-comm.com> a    crit dans le message :
> > 89avoi$bc$1@nnrp1.deja.com...
> > > 10.5 [class.derived] paragraph 5 says:
> > >
> > > [Note: A base class subobject might have a layout (3.7) different
> > > from the layout of a most derived object of the same type. ...]
> >
> > > BTW, 3.9 [basic.types] paragraph 11 says:
> > >
> > > If two types T1 and T2 are the same type, then T1 and T2 are layout-
> > > compatible types.
> > >
> >
> > If two types have the same layout, then the followinf is safe :
> >
> > T1 t1;
> > T2 t2;
> >
> > t1 = *((t1*)(void*)(&t2))
> >
> > But, the first note says that T1 and T2 _might_ have different layouts
> > even if one is a base class of the other.
> >
>
> My points were
>
> (1) there is a defect in 10.5.5, as it refers to a non-existing layout
> definition

Maybe "layout" is a self-descriptive term.
I understand "memory/byte layout".

> (2) the wording in 3.9.11 gives the guarantee that for following class
> definitions
>
> struct A {};
> struct B {};
> struct C: virtual A, virtual B {}
> struct D: C {}
>
> implementation will not change the layout of C subobject in D (e.g. the
> order in which virtual bases are placed inside the subobject). It may
> be important in some cases.

D and C are not the same type.
C and E are the same type when :
  typedef  C E; // ;)
or
  typedef aTemplate<some_args> T1;
  typedef aTemplate<the_same_args> T2;

Xavier Glattard
-- Visiovox Telecom


---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Aleksey Gurtovoy wrote:
>
>
> My points were
>
> (1) there is a defect in 10.5.5, as it refers to a non-existing layout
> definition

It's an English word with no special meaning in the standard. The
standard can't define every word. It must start with some words that
have ordinary meanings.

>
> (2) the wording in 3.9.11 gives the guarantee that for following class
> definitions
>
> struct A {};
> struct B {};
> struct C: virtual A, virtual B {}
> struct D: C {}
>
> implementation will not change the layout of C subobject in D (e.g. the
> order in which virtual bases are placed inside the subobject). It may
> be important in some cases.

I don't see how you can arrive at that conclusion.

Section 3.9 paragraph 11 says that two types are layout-compatible if
they are the same type, and refers to other sections for POD types.
C and D are not PODs, and A, B, C, and D are all different types.
How does that paragraph apply to this case?

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

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38BD57F0.E2282EAB@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> Aleksey Gurtovoy wrote:
> >
> >
> > My points were
> >
> > (1) there is a defect in 10.5.5, as it refers to a non-existing
> > layout definition
>
> It's an English word with no special meaning in the standard. The
> standard can't define every word. It must start with some words that
> have ordinary meanings.
>

Yes, it's an ordinary word with no special meaning in the standard -
after all it is not even italicized :). But when after such a word I
see a cross-reference to other section of the standard - as in 10.5 ("A
base class subobject might have a layout (3.7) ... ") - I expect that
word to appear at least once in the referenced section.

> >
> > (2) the wording in 3.9.11 gives the guarantee that for following
> > class definitions
> >
> > struct A {};
> > struct B {};
> > struct C: virtual A, virtual B {};
> > struct D: C {};
> >
> > implementation will not change the layout of C subobject in D (e.g.
> > the order in which virtual bases are placed inside the subobject).
> > It may be important in some cases.
>
> I don't see how you can arrive at that conclusion.
>
> Section 3.9 paragraph 11 says that two types are layout-compatible if
> they are the same type, and refers to other sections for POD types.
> C and D are not PODs, and A, B, C, and D are all different types.
> How does that paragraph apply to this case?
>

Ok, I'll try again:

1) A base class subobject in a derived object still has the same type
as an ordinary object of that base class (right?)

2) 3.9 [basic.types] paragraph 11 says: "If two types T1 and T2 are the
same type, then T1 and T2 are layout-compatible types".

Therefore
3) the layout of base class subobjects in objects of derived classes
must be the same as the layout of  'standalone' objects of that base
class.

In my example, a layout of c1 and c2 must be the same:

C c1;
const C& c2 = D();

--
-Alexy


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Aleksey Gurtovoy wrote:
>
> In article <38BD57F0.E2282EAB@sun.com>,
>   Steve Clamage <stephen.clamage@sun.com> wrote:
> > Aleksey Gurtovoy wrote:
> > >
> > > (2) the wording in 3.9.11 gives the guarantee that for following
> > > class definitions
> > >
> > > struct A {};
> > > struct B {};
> > > struct C: virtual A, virtual B {};
> > > struct D: C {};
> > >
> > > implementation will not change the layout of C subobject in D (e.g.
> > > the order in which virtual bases are placed inside the subobject).
> > > It may be important in some cases.
> >
> > I don't see how you can arrive at that conclusion.
> >
> > Section 3.9 paragraph 11 says that two types are layout-compatible if
> > they are the same type, and refers to other sections for POD types.
> > C and D are not PODs, and A, B, C, and D are all different types.
> > How does that paragraph apply to this case?
>
> Ok, I'll try again:
>
> 1) A base class subobject in a derived object still has the same type
> as an ordinary object of that base class (right?)

Yes.

>
> 2) 3.9 [basic.types] paragraph 11 says: "If two types T1 and T2 are the
> same type, then T1 and T2 are layout-compatible types".

Yes.

>
> Therefore
> 3) the layout of base class subobjects in objects of derived classes
> must be the same as the layout of  'standalone' objects of that base
> class.
>
> In my example, a layout of c1 and c2 must be the same:
>
> C c1;
> const C& c2 = D();

No. First of all, it says "layout-compatible", not "the layout is
the same". Secondly, "layout-compatible" is in italics, meaning it is
a term requiring definition. (That sentence is part of the definition.)
The term is defined for POD-classes but not for non-POD classes.
Since the term is not defined for general classes, you can't infer
a particular meaning. All you know is that the specified properties
(if any) of layout-compatible types are satisfied.

Consider this addition to your example, but assuming that all classes
are non-empty:

class E : public C, D { ... };

We now have two C subobjects, but only one copy of the virtual base
class subobjects A and B. The positions of A and B relative to each
of the C subobjects cannot be the same.

The term "layout-compatible" was introduced to provide the same
guarantees as in C for C-compatible objects.

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

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

10.5 [class.derived] paragraph 5 says:

[Note: A base class subobject might have a layout (3.7) different from
the layout of a most derived object of the same type. ...]

But section 3.7 doesn't say anything about the class objects layout or
about 'layout' in general. Moreover, there are no definition of
the 'layout' at all. Was it considered a self-descriptive term? There
are a few definitions of the 'layout-compatible' types, but.. it's
worth to define what a layout is about, before you talk about layout-
compatibility, right?

BTW, 3.9 [basic.types] paragraph 11 says:

If two types T1 and T2 are the same type, then T1 and T2 are layout-
compatible types.

As far as I understand, a base class subobject in a derived object
still has the same type as an ordinary object of that base class :). So
a compiler can't change the layout of base class subobjects inside
objects of derived classes - even if the subobjects itself inherit from
several virtual base classes...
Or am I missing something?

--
-Alexy


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

Aleksey Gurtovoy <alexy@meta-comm.com> a    crit dans le message :
89avoi$bc$1@nnrp1.deja.com...
> 10.5 [class.derived] paragraph 5 says:
>
> [Note: A base class subobject might have a layout (3.7) different from
> the layout of a most derived object of the same type. ...]

> BTW, 3.9 [basic.types] paragraph 11 says:
>
> If two types T1 and T2 are the same type, then T1 and T2 are layout-
> compatible types.
>
> As far as I understand, a base class subobject in a derived object
> still has the same type as an ordinary object of that base class :). So
> a compiler can't change the layout of base class subobjects inside
> objects of derived classes - even if the subobjects itself inherit from
> several virtual base classes...

If two types have the same layout, then the followinf is safe :

T1 t1;
T2 t2;

t1 = *((t1*)(void*)(&t2))

But, the first note says that T1 and T2 _might_ have different layouts
even if one is a base class of the other.

Xavier Glattard
-- Visiovox Telecom



---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]

In article <38BDA693.21FE210D@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> > Aleksey Gurtovoy wrote:
> >
> > 1) A base class subobject in a derived object still has the same
> > type as an ordinary object of that base class (right?)
>
> Yes.
>
> >
> > 2) 3.9 [basic.types] paragraph 11 says: "If two types T1 and T2 are
> > the same type, then T1 and T2 are layout-compatible types".
>
> Yes.
>
> >
> > Therefore
> > 3) the layout of base class subobjects in objects of derived classes
> > must be the same as the layout of  'standalone' objects of that base
> > class.
> >
>
> No. First of all, it says "layout-compatible", not "the layout is
> the same". Secondly, "layout-compatible" is in italics, meaning it is
> a term requiring definition. (That sentence is part of the
> definition.) The term is defined for POD-classes but not for non-POD
> classes. Since the term is not defined for general classes, you can't
> infer a particular meaning. All you know is that the specified
> properties (if any) of layout-compatible types are satisfied.
>

It makes sense. Now I understand the issue quite clearly - thanks Steve.

But what about the first cross-reference in 10 [class.derived]
paragraph 5 (sorry for citing this once more):

[Note: A base class subobject might have a layout (3.7) different from
the layout of a most derived object of the same type. ...]

There is nothing relevant to this sentence in section 3.7 [basic.stc]
("Storage duration"). Is the reference incorrect?

--
-Alexy


Sent via Deja.com http://www.deja.com/
Before you buy.

---
[ 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    ]
[              --- Please see the FAQ before posting. ---               ]
[ FAQ: http://reality.sgi.com/austern_mti/std-c++/faq.html              ]