In article <38532294.1A04C78E@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Bart van Tongeren wrote:
> > ...
> > The proof is by negative demonstration:
> > If a type were not layout-compatible with the same type, then
>
> That's not what I'm claiming. I think there's been some confusion; I at
> least am confused by your reply.

Indeed. I'm sorry if I have not been clear enough.

> ... The position you seem to be attributing to me:
> All types would be guaranteed to not be layout compatible with
> themselves.

No, I only tried to show the absurt and conflicting situation that
would arise in the hypothetical case that a type is not layout-
compatible with itself. I did not attribute a position to you.

> > So, a type must be layout compatible with the same type. It follows
> > from the requirements on layout compatible enums and POD structs/unions.
>
> No - if you drop 3.9p11, then some types would still be guaranteed to be
> layout compatible with themselves. However, this would only be the case
> for enumerations, and some kinds of POD-structs, and POD-unions.

Indeed. That's why I think that a more general definition of layout-
compatibility would be useful, that would e.g. also cover
implementation defined pairs of integral types.
Note that, in general, layout-compatible enum pairs are just as well
implementation defined (because their underlying types are; only if
their ranges span the same number of bits, they are pretty sure layout-
compatible).

> ....
> > a final summary why this is indeed the reason that I think there is
> > missing an actual explicit definition of the concept of layout-
> > compatibility between types. This definition could refer to the object-
> > and value representation of such types.
>
> But that would be useless; compatible representation is the conclusion
> you're allowed to reach from layout compatibility; it isn't the evidence
> you use to identify layout compatibility.

Agreed, the programmer cannot use that in itself to determine which
types are layout-compatible. However, the standard determines which POD
structs/unions are layout compatible, and the implementation defines
e.g. which enum (see above) or other integral types will be layout-
compatible. Armed with this knowledge, the programmer could then check
the standard to see what [the currently missing generic definition of]
this layout-compatibility means in terms of sameness of object- and
value-representation. He could then e.g. learn that he could memcpy an
object to an object of layout-compatible type.

Note that non-POD types are never layout-compatible, and the only
remaining pairs of types are pairs of the same type. And each type can
only be defined once.

Well, there seems to be no support for my point of view, so I will
rest my case.

Regards, Bart

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

James Kuyper <kuyper@wizard.net> wrote:

> Bart van Tongeren wrote:
> >=20
> > In article <38500146.1CE5FF07@wizard.net>,
> >   James Kuyper <kuyper@wizard.net> wrote:

> > > If it were in fact not needed, then that conclusion would have to b=
e
> > > provable from other statements in the standard. If that statement w=
ere
> > > removed, what sections of the standard could you cite to prove that=
 a
> > > type is layout compatible with itself?
> >=20
> > The proof is by negative demonstration:
> > If a type were not layout-compatible with the same type, then
>=20
> That's not what I'm claiming. I think there's been some confusion; I at
> least am confused by your reply. Here's my understanding of our
> positions about what would be true if 3.9 p11 were dropped:
>=20
> My position:
> No type would be guaranteed layout compatible with itself, except
> insofar as it's covered by either section 7.2 or 9.2.
>=20
> My understanding of your position:
> All types would still be guaranteed layout compatible with themselves.
>=20
> The position you seem to be attributing to me:
> All types would be guaranteed to not be layout compatible with
> themselves.

I dont think he is attributing that position to you. He tries to prove
his claim by showing that it's negation leads to a contradiction or
otherwise absurd consequences. He call this "negative demonstration".

> > - enums that have the same underlying type could not be layout
> > compatible (see 7.2), because their underlying types would not be.
...
> > - POD structs/unions could not be layout compatible (see 9.2), becaus=
e
> > their corresponding members of the same type would not be.

This indicates a flaw in the argument though. The opposite of "all types
are layout compatible with themselves" is not "no type is layout
compatible with itself" but "some types are not layoutcompatible with
themselves".
To prove his point he can not rely on any particular type not being
layout-compatible with itself. He'd have to argue from the assumption
"There is a type that is not layout-compatible with itself", but that
basis is too vague for the argument.
=20
> > So, a type must be layout compatible with the same type. It follows
> > from the requirements on layout compatible enums and POD structs/unio=
ns.

This would also not follow. Even if the argument did prove this
conclusion from the assumption, that would just maen that no type is
guaranteed by the standard to be layout-compatible to another type.
So applications of layout-compatibility would be implementation-defined.

One might consider that a defect, but there would be an easy solution:
reinstate 3.9/11 :)
=20
A look at the issues lists shows, that you can't deduce anything from
the Standard by showing that absence of that feature would make the
Standard defective.

> No - if you drop 3.9p11, then some types would still be guaranteed to b=
e
> layout compatible with themselves. However, this would only be the case
> for enumerations, and some kinds of POD-structs, and POD-unions. The
> only POD-structs and POD-unions that would be guaranteed layout
> compatible with themselves would be those whose members were all,
> recursively, types that were guranteed layout compatible with
> themselves.=20

Not the most interesting types IMHO.=20
As the pairs of enumeration types to which this applies are generally
implementation-defined, you cannot (portably) store much data in objects
of those types. But I'm sure you are aware of that...
=20
> ....
> > a final summary why this is indeed the reason that I think there is
> > missing an actual explicit definition of the concept of layout-
> > compatibility between types. This definition could refer to the objec=
t-
> > and value representation of such types.

For this to be useful, the standard would have to put some more
requirements on the object- and  representation of various types,
especially on pairs of otherwise unrelated types.=20
Afaics the concept of layout-compatibility is intended to allow posing
such requirements in an abstract way.=20

> But that would be useless; compatible representation is the conclusion
> you're allowed to reach from layout compatibility; it isn't the evidenc=
e
> you use to identify layout compatibility. If you had to know that two
> types had the same representation before you could identify them as
> layout compatible, how could you write code accordingly? The
> representations are implementation-defined; you could never use
> layout-compatibilty in portable code. For my purposes, the concept woul=
d
> be useless, though some people are more willing to tie their code to
> particular implementations than I am.

I agree. You should not promote to assumptions the very things you want
to infer.=20

-- J=F6rg Barfurth
---
[ 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 <38500146.1CE5FF07@wizard.net>,
  James Kuyper <kuyper@wizard.net> wrote:
> Bart van Tongeren wrote:
> ...
> > The 3.9 p11 statement provides no information: it is needless to say
> > that things are compatible after you have said they are same. It could
> > just as well be removed.
>
> If it were in fact not needed, then that conclusion would have to be
> provable from other statements in the standard. If that statement were
> removed, what sections of the standard could you cite to prove that a
> type is layout compatible with itself?

The proof is by negative demonstration:
If a type were not layout-compatible with the same type, then
- enums that have the same underlying type could not be layout
compatible (see 7.2), because their underlying types would not be.
- POD structs/unions could not be layout compatible (see 9.2), because
their corresponding members of the same type would not be.

So, a type must be layout compatible with the same type. It follows
from the requirements on layout compatible enums and POD structs/unions.

> Don't rely on common-sense notions that relate compatibility with
> sameness; in a document of this level of formality, the definitions of
> terms as abstruse as "layout compatibility" belong in the document
> itself, not in the collective consciousness of native speakers of
> English.

I agree that we should not rely too much on "common sense". Let me give
a final summary why this is indeed the reason that I think there is
missing an actual explicit definition of the concept of layout-
compatibility between types. This definition could refer to the object-
and value representation of such types.

Given such a definition, the standard could specify, as in 7.2 and 9.2,
the requirements on pairs of types in order to be layout-compatible.
Furthermore, an implementation could then specify implementation
defined pairs of types that conform to the layout-compatibility concept.
Finally the standard could then specify that it is legal to memcpy an
object to an object of layout-compatible type (I cannot find that
anywhere), and that e.g. pointer casts between them are well behaved
(already in 3.9.2 p3).

> Consider, for example, a "null pointer constant"
> ...

Interesting point; but I doubt if anyone is waiting for another
discussion on null pointers :)

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

Bart van Tongeren wrote:
>
> In article <38500146.1CE5FF07@wizard.net>,
>   James Kuyper <kuyper@wizard.net> wrote:
> > Bart van Tongeren wrote:
> > ...
> > > The 3.9 p11 statement provides no information: it is needless to say
> > > that things are compatible after you have said they are same. It could
> > > just as well be removed.
> >
> > If it were in fact not needed, then that conclusion would have to be
> > provable from other statements in the standard. If that statement were
> > removed, what sections of the standard could you cite to prove that a
> > type is layout compatible with itself?
>
> The proof is by negative demonstration:
> If a type were not layout-compatible with the same type, then

That's not what I'm claiming. I think there's been some confusion; I at
least am confused by your reply. Here's my understanding of our
positions about what would be true if 3.9 p11 were dropped:

My position:
No type would be guaranteed layout compatible with itself, except
insofar as it's covered by either section 7.2 or 9.2.

My understanding of your position:
All types would still be guaranteed layout compatible with themselves.

The position you seem to be attributing to me:
All types would be guaranteed to not be layout compatible with
themselves.

> - enums that have the same underlying type could not be layout
> compatible (see 7.2), because their underlying types would not be.

7.2 p4 says "Two enumeration types are layout-compatible if they have
the same _underlying type_." It says nothing about the underlying types
being layout compatible, only about them being the same.

Thus, dropping 3.9p11 would leave us in the absurd situation where 'int'
wasn't guaranteed layout compatible with itself, but enumerations of
different types could be layout compatible with each other - because
they shared that underlying type.

> - POD structs/unions could not be layout compatible (see 9.2), because
> their corresponding members of the same type would not be.

Why not? The corresponding members could be enumerations, POD-structs,
or POD-unions. All of those are types which could be guaranteed layout
compatible with themselves even without 3.9 p11.

> So, a type must be layout compatible with the same type. It follows
> from the requirements on layout compatible enums and POD structs/unions.

No - if you drop 3.9p11, then some types would still be guaranteed to be
layout compatible with themselves. However, this would only be the case
for enumerations, and some kinds of POD-structs, and POD-unions. The
only POD-structs and POD-unions that would be guaranteed layout
compatible with themselves would be those whose members were all,
recursively, types that were guranteed layout compatible with
themselves.

....
> a final summary why this is indeed the reason that I think there is
> missing an actual explicit definition of the concept of layout-
> compatibility between types. This definition could refer to the object-
> and value representation of such types.

But that would be useless; compatible representation is the conclusion
you're allowed to reach from layout compatibility; it isn't the evidence
you use to identify layout compatibility. If you had to know that two
types had the same representation before you could identify them as
layout compatible, how could you write code accordingly? The
representations are implementation-defined; you could never use
layout-compatibilty in portable code. For my purposes, the concept would
be useless, though some people are more willing to tie their code to
particular implementations than I am.
---
[ 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              ]

"James Kuyper Jr." <kuyper@wizard.net> wrote:
| Bart van Tongeren wrote:
| > I still feel somewhat shaky with the standard's complicated definition
| > of layout-compatibility. Furthermore, my simple mind insists that it is
| > unnecessary, if not meaningless, to ascribe such a compatibility concept
| > for the same type(s) as in 3.9 p11. I would prefer the following to
| > define layout-compatibility for a pair of POD-types:
| >     "Given two layout-compatible POD types T1 and T2, a T1 object can be
| > copied into an array of unsigned char. If that array is then copied into
| > a T2 object, these objects will have both the same object representation
| > and the same value."
|
| Without the statement that any type T is layout-compatible with
| itself, you'd be left with the absurdity of allowing bytewise
| copies to layout-compatible types, but not to the same type.

Well, that is already covered by 3.9 p3:
    "For any POD type T, if two pointers to T point to distinct
objects obj1 and obj2, if the value of obj1 is copied into obj2,
using the memcpy library function, obj2 shall subsequently hold
the same value as obj1."

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

In article <3846BC15.29EC7CB4@sun.com>,
  Steve Clamage <stephen.clamage@sun.com> wrote:
> Bart van Tongeren wrote:
> >
> > The ISO C++ standard, section 3.9, paragraph 11, says:
> >     If two types T1 and T2 are the same type, then T1 and T2  are
> > layout-compatible types.
> >
> > While I cannot deny this, I wonder if this statement tries to say
more
> > than that a type T is layout-compatible with itself. It does not
define
> > the concept of layout-compatibility. Is this a defect?
> >
> ...
> Without the definition that a type is
> layout-compatible with itself, it is pretty difficult to define
> layout-compatibility of different types.

In my opinion, a much more straightforward definition is possible; see
my earlier reply in another sub-thread in this discusssion where I
propose an actual definition of what layout-compatibility means.
The 3.9 p11 statement provides no information: it is needless to say
that things are compatible after you have said they are same. It could
just as well be removed.

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

Bart van Tongeren wrote:

> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:38485DAC.9AD5BA16@wizard.net...

> | a built-in type T1 is layout compatible
> | with type T2 if T2 is the same as T1; otherwise it isn't.
>
> I doubt the "otherwise it isn't".

That's hair-splitting, to say the least. We are talking
about the least possible interpretation of layout-compatible.

> I still feel somewhat shaky with the standard's complicated definition
> of layout-compatibility.

I have copied-paste the definition of layout-compatibility
(having to read something splitered everywhere is anoying).
It seems absolutely clear. What is the problem ?

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

-7- Two enumeration types are layout-compatible if they have the same
underlying type.

-14- Two POD-struct (clause class) types are layout-compatible if they
have
the same number of members, and corresponding members (in order) have
layout-compatible types (basic.types).

-15- Two POD-union (clause class) types are layout-compatible if they
have
the same number of members, and corresponding members (in any order)
have
layout-compatible types (basic.types).

> Furthermore, my simple mind insists that it is
> unnecessary, if not meaningless, to ascribe such a compatibility concept
> for the same type(s) as in 3.9 p11.

It's meaningful and necessary. Enhance your mind. (Read
the standard.)

> I would prefer the following to
> define layout-compatibility for a pair of POD-types:
>     "Given two layout-compatible POD types T1 and T2, ..."

It isn't a definition of layout-compatibility. Thanks for playing
with us.

--

Valentin Bonnard
---
[ 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              ]

Valentin Bonnard <Bonnard.V@wanadoo.fr> wrote:
> Bart van Tongeren wrote:
> > "James Kuyper Jr." <kuyper@wizard.net> wrote:
> ... Thanks for playing with us.

I regret both that I could not make clear my point (whether it's right
or wrong) to you, and that you got the impression I was playing with
anyone. It is not true, and James Kuyper's reply to my message also does
not indicate that. But I only speak for myself.

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

Bart van Tongeren wrote:
...
> The 3.9 p11 statement provides no information: it is needless to say
> that things are compatible after you have said they are same. It could
> just as well be removed.

If it were in fact not needed, then that conclusion would have to be
provable from other statements in the standard. If that statement were
removed, what sections of the standard could you cite to prove that a
type is layout compatible with itself?

Don't rely on common-sense notions that relate compatibility with
sameness; in a document of this level of formality, the definitions of
terms as abstruse as "layout compatibility" belong in the document
itself, not in the collective consciousness of native speakers of
English.
Consider, for example, a "null pointer constant", which in C isn't
guaranteed to be a pointer, and in C++ is actually prohibited from being
a pointer. It is, however, both null, and a constant; two out of three
isn't bad :-)
---
[ 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              ]

"James Kuyper Jr." <kuyper@wizard.net> wrote in message
news:38485DAC.9AD5BA16@wizard.net...
| Bart van Tongeren wrote:
| > The recursion is not ended, because 3.9 does not define what layout-
| > compatibility is for built-in types, nor what you can do with it.
|
| Yes it does. Built-in types are neither enumerations, POD-structs, nor
| POD-unions; therefore, by 3.9, a built-in type T1 is layout compatible
| with type T2 if T2 is the same as T1; otherwise it isn't.

I doubt the "otherwise it isn't". I think that the standard does
(implicitly) allow an implementation to define e.g. int and long int as
being layout-compatible types.

| ....
| > Indeed, after reading 3.9, 7.2, and 9.2, then you know when two
types
| > are layout-compatible. But, it does not say what it gives you when
two
| > types are layout-compatible. Of course, the name is suggestive, but
| > why not define what it means?
| >
| > The only mentioned use of layout-compatibility is, for as far as I
| > know, stated in section 3.9.2 paragraph 3. It concerns the equality
of
| > value representation and alignment requirements of pointers to
layout-
| > compatible types.
|
| You've got it. The statement that the value representations are the
same
| is, in particular, a very powerful one.

But this concerns the value representations of the pointers, not the
pointees.. The above (3.9.2 p3) does not say that layout-compatible
types have the same value representation.

| There's one other relevant use in section 9.2 p16: "If a POD-union
| contains two or more POD-structs that share a common initial sequence,
| and if the POD-union currently contains one of these POD-structs, it
is
| permitted to inspect the common initial part of any of them. Two
| POD-structs share a common initial sequence if corresponding members
| have layout compatible types (and, for bit-fields, the same width) for
a
| sequence of one or more initial members."

Okay, now I agree that this indeed appears to imply that
layout-compatible POD structs are copyable in the way I mentioned. It
means such types have the same value representation.

I still feel somewhat shaky with the standard's complicated definition
of layout-compatibility. Furthermore, my simple mind insists that it is
unnecessary, if not meaningless, to ascribe such a compatibility concept
for the same type(s) as in 3.9 p11. I would prefer the following to
define layout-compatibility for a pair of POD-types:
    "Given two layout-compatible POD types T1 and T2, a T1 object can be
copied into an array of unsigned char. If that array is then copied into
a T2 object, these objects will have both the same object representation
and the same value."
This also covers implementation defined layout-compatibility between
different integral types.

Best regards,
Bart van Tongeren

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

Bart van Tongeren wrote:
>
> "James Kuyper Jr." <kuyper@wizard.net> wrote in message
> news:38485DAC.9AD5BA16@wizard.net...
> | Bart van Tongeren wrote:
> | > The recursion is not ended, because 3.9 does not define what layout-
> | > compatibility is for built-in types, nor what you can do with it.
> |
> | Yes it does. Built-in types are neither enumerations, POD-structs, nor
> | POD-unions; therefore, by 3.9, a built-in type T1 is layout compatible
> | with type T2 if T2 is the same as T1; otherwise it isn't.
>
> I doubt the "otherwise it isn't". I think that the standard does
> (implicitly) allow an implementation to define e.g. int and long int as
> being layout-compatible types.

I'm sorry, you're correct. I should have said that the standard defines
which pairs of types can be portably known to be layout compatible.
Other pairs might happen to be layout compatible, but code which relies
on that will be non-portable. There are implementations where 'signed
char' and 'long' are layout compatible, and some pairs of non-POD struct
or union types may be layout compatible. I suspect that most unions are
layout-compatible with their largest member types.

....
> | > The only mentioned use of layout-compatibility is, for as far as I
> | > know, stated in section 3.9.2 paragraph 3. It concerns the equality
> of
> | > value representation and alignment requirements of pointers to
> layout-
> | > compatible types.
> |
> | You've got it. The statement that the value representations are the
> same
> | is, in particular, a very powerful one.
>
> But this concerns the value representations of the pointers, not the
> pointees.. The above (3.9.2 p3) does not say that layout-compatible
> types have the same value representation.

You're right. I misread that.

....
> I still feel somewhat shaky with the standard's complicated definition
> of layout-compatibility. Furthermore, my simple mind insists that it is
> unnecessary, if not meaningless, to ascribe such a compatibility concept
> for the same type(s) as in 3.9 p11. I would prefer the following to
> define layout-compatibility for a pair of POD-types:
>     "Given two layout-compatible POD types T1 and T2, a T1 object can be
> copied into an array of unsigned char. If that array is then copied into
> a T2 object, these objects will have both the same object representation
> and the same value."

Without the statement that any type T is layout-compatible with itself,
you'd be left with the absurdity of allowing bytewise copies to
layout-compatible types, but not to the same type.
---
[ 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              ]

Bart van Tongeren wrote:
>
> The ISO C++ standard, section 3.9, paragraph 11, says:
>     If two types T1 and T2 are the same type, then T1 and T2  are
> layout-compatible types.
>
> While I cannot deny this, I wonder if this statement tries to say more
> than that a type T is layout-compatible with itself. It does not define
> the concept of layout-compatibility. Is this a defect?
>

See clause 9.2 for further discussion of layout-compatible.

--
Pete Becker
Dinkumware, Ltd.
http://www.dinkumware.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              ]

Valentin Bonnard wrote:
>
> Bart van Tongeren wrote:
>
> > The ISO C++ standard, section 3.9, paragraph 11, says:
> >     If two types T1 and T2 are the same type, then T1 and T2  are
> > layout-compatible types.
> >
> > While I cannot deny this, I wonder if this statement tries to say more
> > than that a type T is layout-compatible with itself. It does not define
> > the concept of layout-compatibility. Is this a defect?
>
> The defect is that layout-compatibility is strictly useless.

C defines the concept of layout-compatible types. If you declare two
structs with compatible member types in the same order, they are layout-
compatible. Pointer casts involving those types are well-behaved, for
example.

C++ provides the same guarantees as C for POD types.

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

Bart van Tongeren wrote:
>
> J.Barfurth <techview@bfk-net.de> schreef in berichtnieuws
> 8274ac$7hp$1@news.hamburg.pop.de...
> | There are many more statements about layout-compatible types scattered
> | throughout the standard. The probably most important part deals with
> POD
> | structs and unions. The definition there is recursive (defined in
> terms
> | of layout-compatibility of corresponding members).
> | It seems that this is the reason to have the above paragraph: it
> | terminates the recursion when you get down to (possibly typedef'd
> | built-ins).
> |
>
> There are not so many of them (at least I didn't find many).
> The recursion is not ended, because 3.9 does not define what layout-
> compatibility is for built-in types, nor what you can do with it.

Yes it does. Built-in types are neither enumerations, POD-structs, nor
POD-unions; therefore, by 3.9, a built-in type T1 is layout compatible
with type T2 if T2 is the same as T1; otherwise it isn't.

....
> Indeed, after reading 3.9, 7.2, and 9.2, then you know when two types
> are layout-compatible. But, it does not say what it gives you when two
> types are layout-compatible. Of course, the name is suggestive, but
> why not define what it means?
>
> The only mentioned use of layout-compatibility is, for as far as I
> know, stated in section 3.9.2 paragraph 3. It concerns the equality of
> value representation and alignment requirements of pointers to layout-
> compatible types.

You've got it. The statement that the value representations are the same
is, in particular, a very powerful one.

There's one other relevant use in section 9.2 p16: "If a POD-union
contains two or more POD-structs that share a common initial sequence,
and if the POD-union currently contains one of these POD-structs, it is
permitted to inspect the common initial part of any of them. Two
POD-structs share a common initial sequence if corresponding members
have layout compatible types (and, for bit-fields, the same width) for a
sequence of one or more initial members."

 union {
     struct{
         int i;
         float f;
     } a;
     struct{
         int i;
         double f;
     } b;
 } u;

 u.a.i = 1;
 u.a.f = 2.0;
 int j = u.b.i; /* Legal */
 double g = u.b.f; /* Not legal */

> So I wonder if there is something missing like:
>   "Given two layout-compatible POD types T1 and T2, a T1 object can be
> copied into an array of char or unsigned char (see 3.9 paragraph 2). If
> that array is then copied into a T2 object, then the members (in order)
> of both objects have the same values."

For POD types, that's implied by the equality of the value
representations:

3.9 p2: "For any complete POD object type T, ... the underlying bytes
(1.7) making up the object can be copied into an array of char or
unsigned char. 36) If the contents of the array of char or unsigned char
is copied back into the object, the object shall subsequently hold its
original value.

3.9 p4: "The _object representation_ of an object of type T is the
sequence of N unsigned char objects taken up by the object of type T,
where N equals sizeof(T). The _value representation_ of an object is the
set of bits that hold the value of type T. For POD types, the value
representation is a set of bits in the object representation that
determines a _value_, which is one discrete element of an
implementation-defined set of values."

Combined, these imply the conclusion you described.
---
[ 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              ]

Bart van Tongeren wrote:
>
> The ISO C++ standard, section 3.9, paragraph 11, says:
>     If two types T1 and T2 are the same type, then T1 and T2  are
> layout-compatible types.
>
> While I cannot deny this, I wonder if this statement tries to say more
> than that a type T is layout-compatible with itself. It does not define
> the concept of layout-compatibility. Is this a defect?
>

If you read the rest of the same paragraph, you will see that it
refers you to other sections that define more interesting cases
of layout compatibility. Without the definition that a type is
layout-compatible with itself, it is pretty difficult to define
layout-compatibility of different types.

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

The ISO C++ standard, section 3.9, paragraph 11, says:
    If two types T1 and T2 are the same type, then T1 and T2  are
layout-compatible types.

While I cannot deny this, I wonder if this statement tries to say more
than that a type T is layout-compatible with itself. It does not define
the concept of layout-compatibility. Is this a defect?

--
-- reply to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]

Bart van Tongeren <bart_van_tongeren@my-deja.com> schrieb in im
Newsbeitrag: 826cvu$k7a$1@nnrp1.deja.com...
>
> The ISO C++ standard, section 3.9, paragraph 11, says:
>     If two types T1 and T2 are the same type, then T1 and T2  are
> layout-compatible types.
>
> While I cannot deny this, I wonder if this statement tries to say more
> than that a type T is layout-compatible with itself. It does not
define
> the concept of layout-compatibility. Is this a defect?

There are many more statements about layout-compatible types scattered
throughout the standard. The probably most important part deals with POD
structs and unions. The definition there is recursive (defined in terms
of layout-compatibility of corresponding members).
It seems that this is the reason to have the above paragraph: it
terminates the recursion when you get down to (possibly typedef'd
built-ins).

-- J   rg Barfurth





[ 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              ]

Bart van Tongeren wrote:
>
> The ISO C++ standard, section 3.9, paragraph 11, says:
>     If two types T1 and T2 are the same type, then T1 and T2  are
> layout-compatible types.
>
> While I cannot deny this, I wonder if this statement tries to say more
> than that a type T is layout-compatible with itself. It does not define
> the concept of layout-compatibility. Is this a defect?

Read the note at the end of that paragraph: "Layout compatible
enumerations are described in 7.2. Layout-compatible POD-structs and
POD-unions are described in 9.2". You need to look at all three sections
to get the complete definition of layout compatibility. If a given pair
of types is not covered by one of those sections, they're not layout
compatible.



[ 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              ]

Bart van Tongeren wrote:

> The ISO C++ standard, section 3.9, paragraph 11, says:
>     If two types T1 and T2 are the same type, then T1 and T2  are
> layout-compatible types.
>
> While I cannot deny this, I wonder if this statement tries to say more
> than that a type T is layout-compatible with itself. It does not define
> the concept of layout-compatibility. Is this a defect?

The defect is that layout-compatibility is strictly useless.

--

Valentin Bonnard


[ 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              ]

Valentin Bonnard wrote:
>
> Bart van Tongeren wrote:
>
> > The ISO C++ standard, section 3.9, paragraph 11, says:
> >     If two types T1 and T2 are the same type, then T1 and T2  are
> > layout-compatible types.
> >
> > While I cannot deny this, I wonder if this statement tries to say more
> > than that a type T is layout-compatible with itself. It does not define
> > the concept of layout-compatibility. Is this a defect?
>
> The defect is that layout-compatibility is strictly useless.

Could you explain that? The standard currently makes a few guarantees
that apply only to layout-compatible types; counting on those guarantees
when, and only when, they apply seems to me to be fairly useful.


[ 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              ]

J.Barfurth <techview@bfk-net.de> schreef in berichtnieuws
8274ac$7hp$1@news.hamburg.pop.de...
| There are many more statements about layout-compatible types scattered
| throughout the standard. The probably most important part deals with
POD
| structs and unions. The definition there is recursive (defined in
terms
| of layout-compatibility of corresponding members).
| It seems that this is the reason to have the above paragraph: it
| terminates the recursion when you get down to (possibly typedef'd
| built-ins).
|

There are not so many of them (at least I didn't find many).
The recursion is not ended, because 3.9 does not define what layout-
compatibility is for built-in types, nor what you can do with it.

In article <38470955.783E2803@wizard.net>,
  "James Kuyper Jr." <kuyper@wizard.net> wrote:
> Read the note at the end of that paragraph: "Layout compatible
> enumerations are described in 7.2. Layout-compatible POD-structs and
> POD-unions are described in 9.2". You need to look at all three sections
> to get the complete definition of layout compatibility. If a given pair
> of types is not covered by one of those sections, they're not layout
> compatible.

Indeed, after reading 3.9, 7.2, and 9.2, then you know when two types
are layout-compatible. But, it does not say what it gives you when two
types are layout-compatible. Of course, the name is suggestive, but
why not define what it means?

The only mentioned use of layout-compatibility is, for as far as I
know, stated in section 3.9.2 paragraph 3. It concerns the equality of
value representation and alignment requirements of pointers to layout-
compatible types.

So I wonder if there is something missing like:
  "Given two layout-compatible POD types T1 and T2, a T1 object can be
copied into an array of char or unsigned char (see 3.9 paragraph 2). If
that array is then copied into a T2 object, then the members (in order)
of both objects have the same values."

It seems obviously true, but, so far, I can't proof it using the
standard.

--
-- email to: bart.van.tongeren
-- [no spam please] @chello.nl


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              ]