Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70942 > unrolled thread
| Started by | Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> |
|---|---|
| First post | 2020-01-01 19:24 +0000 |
| Last post | 2020-01-13 16:29 -0800 |
| Articles | 15 on this page of 135 — 18 participants |
Back to article view | Back to comp.lang.c++
Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-01 19:24 +0000
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 09:36 +0000
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 03:34 -0800
Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 12:49 +0100
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 04:52 -0800
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-02 17:22 +0000
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 10:26 -0800
Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-02 21:54 +0000
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:49 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 17:11 +0100
Re: Union type punning in C++ Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-03 17:55 +0000
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 09:55 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 11:20 +0100
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 02:21 -0800
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:55 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 16:04 +0100
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:45 -0800
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:26 +0100
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 16:55 -0800
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 01:02 +0000
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 17:06 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:34 -0800
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 16:12 +0000
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 08:49 -0800
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-03 19:28 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:54 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:25 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:28 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 01:41 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:52 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:08 +0100
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:34 +0100
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 08:43 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:20 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:25 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:25 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:27 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:36 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 08:41 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 09:49 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:01 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:02 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 09:19 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 10:38 +0100
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-04 12:45 +0100
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 12:00 +0000
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 13:03 +0100
Re: Union type punning in C++ Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-04 14:22 +0100
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:46 -0800
Re: Union type punning in C++ Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:32 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 10:43 -0800
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 18:55 +0000
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 09:40 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-08 13:23 -0800
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:41 -0800
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-08 22:52 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-09 12:59 -0800
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-09 13:32 -0800
Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 12:28 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 14:02 +0100
Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-10 16:21 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-10 19:18 +0100
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-10 15:41 -0800
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 12:01 +0100
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 07:05 -0800
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 23:53 +0100
Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-12 01:41 +0000
Re: Union type punning in C++ Daniel <danielaparker@gmail.com> - 2020-01-11 19:00 -0800
Re: Union type punning in C++ Mr Flibble <flibble@i42.removethisbit.co.uk> - 2020-01-13 17:32 +0000
Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:53 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 13:20 +0100
Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 12:33 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-11 14:28 +0100
Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 10:48 +0000
Re: Union type punning in C++ Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-11 11:05 +0000
Re: Union type punning in C++ Mister2U@honorific.org - 2020-01-11 11:55 +0000
Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-02 21:12 +0100
Re: Union type punning in C++ boltar@nowhere.org - 2020-01-03 14:46 +0000
Re: Union type punning in C++ Bo Persson <bo@bo-persson.se> - 2020-01-03 20:01 +0100
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-02 23:23 +0100
Re: Union type punning in C++ peter koch <peter.koch.larsen@gmail.com> - 2020-01-02 12:39 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 15:39 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-02 16:58 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-02 17:55 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 00:40 -0800
Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:04 +0000
Re: Union type punning in C++ David Brown <david.brown@hesbynett.no> - 2020-01-03 15:24 +0100
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:34 -0800
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-03 22:59 +0000
Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:11 +0000
Re: Union type punning in C++ Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-04 00:21 +0000
Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-04 00:26 +0000
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-04 16:51 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 18:47 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 19:07 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 06:47 -0800
Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 14:57 +0000
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 07:38 -0800
Re: Union type punning in C++ Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2020-01-03 17:06 +0000
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 11:05 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-03 14:38 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-03 22:37 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:10 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-11 10:23 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 09:01 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 11:03 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 12:48 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 14:15 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-13 21:47 -0500
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-13 23:44 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 08:26 -0500
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:30 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 09:11 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-14 21:52 -0500
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-14 23:15 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:03 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-11 07:28 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-11 20:40 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 20:16 -0500
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-12 17:28 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-12 21:53 -0500
Re: Union type punning in C++ Manfred <noname@add.invalid> - 2020-01-13 18:50 +0100
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:21 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:57 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:27 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:05 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-14 20:58 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 03:47 -0800
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 01:22 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 08:04 -0500
Re: Union type punning in C++ Öö Tiib <ootiib@hot.ee> - 2020-01-15 09:38 -0800
Re: Union type punning in C++ James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-15 11:01 -0800
Re: Union type punning in C++ Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-13 08:37 -0800
Re: Union type punning in C++ "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-01-13 16:29 -0800
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-12 17:28 -0800 |
| Message-ID | <qvgh2v$md0$1@gioia.aioe.org> |
| In reply to | #71301 |
On 1/12/2020 5:16 PM, James Kuyper wrote:
> On 1/11/20 11:40 PM, Chris M. Thomasson wrote:
>> On 1/11/2020 7:28 AM, Tim Rentsch wrote:
>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> ...
>>>> #include <iostream>
>>>>
>>>> struct base
>>>> {
>>>> int p0;
>>>> };
>>>>
>>>> struct object_0
>>>> {
>>>> base b;
>>>> int p0;
>>>> };
>>>>
>>>> struct object_1
>>>> {
>>>> base b;
>>>> int p0;
>>>> int p1;
>>>> };
>>>>
>>>> union object
>>>> {
>>>> base b;
>>>> object_0 o0;
>>>> object_1 o1;
>>>> };
>>>>
>>>>
>>>> int main() {
>>>> object o;
>>>>
>>>> o.b.p0 = 41;
>>>> o.o0.b.p0 += 1;
>>>> o.o1.b.p0 += 1;
>>>>
>>>> // humm
>>>> int r = o.b.p0; // ub...
>>>>
>>>> std::cout << "r = " << r << "\n";
>>>>
>>>> return 0;
>>>> }
>>>> ___________________________
>>>>
>>>>
>>>> Wrt POD and a common base object on each sub-object in a union, well
>>>> does it bite the dust with UB?
>>>
>>> I believe this runs afoul of the rules for common initial
>>> sequences, because type 'base' has as its first member a type
>>> that is not layout compatible with the type of the first members
>>> of object_0 and object_1.
>>
>> Everything boils down to an int. Therefore, the common initial sequence
>> is an int. It should work. Its all POD, everything has that common int,
>> even in struct base. ...
>
> In a standard-layout union with an active member (9.5) of struct type
> T1, it is permitted to read a non-static data member m of another union
> member of struct type T2 provided m is part of the common initial
> sequence of T1 and T2." (9.2p19).
>
> "The common initial sequence of two standard-layout struct (Clause 9)
> types is the longest sequence of non-static data members and bit-fields
> in declaration order, starting with the first such entity in each of the
> structs, such that corresponding entities have layout-compatible types
> and either neither entity is a bit-field or both are bit-fields with the
> same width." (9.2p16). "common initial sequence" is italicized in that
> text, an ISO convention identifying this sentence as the official
> definition of that term. Nothing in that definition allow you to match
> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
> sequence. It's the corresponding members that have to have
> layout-compatible types, and "struct base" and "int" don't.
Damn. Need to think on this. what about something like:
________________
struct object_0
{
int b; // common initial sequence
int p0;
};
struct object_1
{
int b; // common initial sequence
int p0;
int p1;
};
union object
{
int b; // common initial sequence
object_0 o0;
object_1 o1;
};
________________
? This gets rid of struct base.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-12 21:53 -0500 |
| Message-ID | <qvgm47$gts$1@dont-email.me> |
| In reply to | #71302 |
On 1/12/20 8:28 PM, Chris M. Thomasson wrote:
> On 1/12/2020 5:16 PM, James Kuyper wrote:
...
>> In a standard-layout union with an active member (9.5) of struct type
>> T1, it is permitted to read a non-static data member m of another union
>> member of struct type T2 provided m is part of the common initial
>> sequence of T1 and T2." (9.2p19).
>>
>> "The common initial sequence of two standard-layout struct (Clause 9)
>> types is the longest sequence of non-static data members and bit-fields
>> in declaration order, starting with the first such entity in each of the
>> structs, such that corresponding entities have layout-compatible types
>> and either neither entity is a bit-field or both are bit-fields with the
>> same width." (9.2p16). "common initial sequence" is italicized in that
>> text, an ISO convention identifying this sentence as the official
>> definition of that term. Nothing in that definition allow you to match
>> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
>> sequence. It's the corresponding members that have to have
>> layout-compatible types, and "struct base" and "int" don't.
>
> Damn. Need to think on this. what about something like:
> ________________
> struct object_0
> {
> int b; // common initial sequence
> int p0;
> };
>
> struct object_1
> {
> int b; // common initial sequence
> int p0;
> int p1;
> };
>
> union object
> {
> int b; // common initial sequence
> object_0 o0;
> object_1 o1;
> };
> ________________
>
> ? This gets rid of struct base.
9.2p19 Only applies when the two union members involved are both of
struct type. o.o0 and o.o1 share a common initial sequence, but neither
one shares one with o.b, since o.b doesn't have a struct type.
This is a trivial problem to workaround. Why do you need o.b? For
whatever purpose you need it, why couldn't you use o.o0.b or o.o1.b (it
doesn't matter which one you choose - which is the whole point) instead?
[toc] | [prev] | [next] | [standalone]
| From | Manfred <noname@add.invalid> |
|---|---|
| Date | 2020-01-13 18:50 +0100 |
| Message-ID | <qviakn$rhf$1@gioia.aioe.org> |
| In reply to | #71303 |
On 1/13/2020 3:53 AM, James Kuyper wrote:
> On 1/12/20 8:28 PM, Chris M. Thomasson wrote:
>> On 1/12/2020 5:16 PM, James Kuyper wrote:
> ...
>>> In a standard-layout union with an active member (9.5) of struct type
>>> T1, it is permitted to read a non-static data member m of another union
>>> member of struct type T2 provided m is part of the common initial
>>> sequence of T1 and T2." (9.2p19).
>>>
>>> "The common initial sequence of two standard-layout struct (Clause 9)
>>> types is the longest sequence of non-static data members and bit-fields
>>> in declaration order, starting with the first such entity in each of the
>>> structs, such that corresponding entities have layout-compatible types
>>> and either neither entity is a bit-field or both are bit-fields with the
>>> same width." (9.2p16). "common initial sequence" is italicized in that
>>> text, an ISO convention identifying this sentence as the official
>>> definition of that term. Nothing in that definition allow you to match
>>> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
>>> sequence. It's the corresponding members that have to have
>>> layout-compatible types, and "struct base" and "int" don't.
>>
>> Damn. Need to think on this. what about something like:
>> ________________
>> struct object_0
>> {
>> int b; // common initial sequence
>> int p0;
>> };
>>
>> struct object_1
>> {
>> int b; // common initial sequence
>> int p0;
>> int p1;
>> };
>>
>> union object
>> {
>> int b; // common initial sequence
>> object_0 o0;
>> object_1 o1;
>> };
>> ________________
>>
>> ? This gets rid of struct base.
>
> 9.2p19 Only applies when the two union members involved are both of
> struct type. o.o0 and o.o1 share a common initial sequence, but neither
> one shares one with o.b, since o.b doesn't have a struct type.
>
> This is a trivial problem to workaround. Why do you need o.b? For
> whatever purpose you need it, why couldn't you use o.o0.b or o.o1.b (it
> doesn't matter which one you choose - which is the whole point) instead?
>
If o.b is intended to be a common base, it could be trivially defined as
such:
struct object_base
{
int b;
};
union object
{
object_base ob;
object_0 o0;
object_1 o1;
};
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-13 16:21 -0800 |
| Message-ID | <qvj1iu$3d1$1@gioia.aioe.org> |
| In reply to | #71303 |
On 1/12/2020 6:53 PM, James Kuyper wrote:
> On 1/12/20 8:28 PM, Chris M. Thomasson wrote:
>> On 1/12/2020 5:16 PM, James Kuyper wrote:
> ...
>>> In a standard-layout union with an active member (9.5) of struct type
>>> T1, it is permitted to read a non-static data member m of another union
>>> member of struct type T2 provided m is part of the common initial
>>> sequence of T1 and T2." (9.2p19).
>>>
>>> "The common initial sequence of two standard-layout struct (Clause 9)
>>> types is the longest sequence of non-static data members and bit-fields
>>> in declaration order, starting with the first such entity in each of the
>>> structs, such that corresponding entities have layout-compatible types
>>> and either neither entity is a bit-field or both are bit-fields with the
>>> same width." (9.2p16). "common initial sequence" is italicized in that
>>> text, an ISO convention identifying this sentence as the official
>>> definition of that term. Nothing in that definition allow you to match
>>> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
>>> sequence. It's the corresponding members that have to have
>>> layout-compatible types, and "struct base" and "int" don't.
>>
>> Damn. Need to think on this. what about something like:
>> ________________
>> struct object_0
>> {
>> int b; // common initial sequence
>> int p0;
>> };
>>
>> struct object_1
>> {
>> int b; // common initial sequence
>> int p0;
>> int p1;
>> };
>>
>> union object
>> {
>> int b; // common initial sequence
>> object_0 o0;
>> object_1 o1;
>> };
>> ________________
>>
>> ? This gets rid of struct base.
>
> 9.2p19 Only applies when the two union members involved are both of
> struct type. o.o0 and o.o1 share a common initial sequence, but neither
> one shares one with o.b, since o.b doesn't have a struct type.
>
> This is a trivial problem to workaround. Why do you need o.b? For
> whatever purpose you need it, why couldn't you use o.o0.b or o.o1.b (it
> doesn't matter which one you choose - which is the whole point) instead?
>
Excellent point. Added it there when I quickly typed this code in.
Therefore, I do not have a solid answer. However, perhaps it had
something to do with thinking that o.b should map to o.o0.b and o.o1.b.
All are one and one is all type of union relationship here. My bad.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-13 08:57 -0800 |
| Message-ID | <86v9pfguqn.fsf@linuxsc.com> |
| In reply to | #71302 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> On 1/12/2020 5:16 PM, James Kuyper wrote:
>
>> On 1/11/20 11:40 PM, Chris M. Thomasson wrote:
>>
>>> On 1/11/2020 7:28 AM, Tim Rentsch wrote:
>>>
>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>
>> ...
>>
>>>>> #include <iostream>
>>>>>
>>>>> struct base
>>>>> {
>>>>> int p0;
>>>>> };
>>>>>
>>>>> struct object_0
>>>>> {
>>>>> base b;
>>>>> int p0;
>>>>> };
>>>>>
>>>>> struct object_1
>>>>> {
>>>>> base b;
>>>>> int p0;
>>>>> int p1;
>>>>> };
>>>>>
>>>>> union object
>>>>> {
>>>>> base b;
>>>>> object_0 o0;
>>>>> object_1 o1;
>>>>> };
>>>>>
>>>>>
>>>>> int main() {
>>>>> object o;
>>>>>
>>>>> o.b.p0 = 41;
>>>>> o.o0.b.p0 += 1;
>>>>> o.o1.b.p0 += 1;
>>>>>
>>>>> // humm
>>>>> int r = o.b.p0; // ub...
>>>>>
>>>>> std::cout << "r = " << r << "\n";
>>>>>
>>>>> return 0;
>>>>> }
>>>>> ___________________________
>>>>>
>>>>>
>>>>> Wrt POD and a common base object on each sub-object in a union, well
>>>>> does it bite the dust with UB?
>>>>
>>>> I believe this runs afoul of the rules for common initial
>>>> sequences, because type 'base' has as its first member a type
>>>> that is not layout compatible with the type of the first members
>>>> of object_0 and object_1.
>>>
>>> Everything boils down to an int. Therefore, the common initial sequence
>>> is an int. It should work. Its all POD, everything has that common int,
>>> even in struct base. ...
>>
>> In a standard-layout union with an active member (9.5) of struct type
>> T1, it is permitted to read a non-static data member m of another union
>> member of struct type T2 provided m is part of the common initial
>> sequence of T1 and T2." (9.2p19).
>>
>> "The common initial sequence of two standard-layout struct (Clause 9)
>> types is the longest sequence of non-static data members and bit-fields
>> in declaration order, starting with the first such entity in each of the
>> structs, such that corresponding entities have layout-compatible types
>> and either neither entity is a bit-field or both are bit-fields with the
>> same width." (9.2p16). "common initial sequence" is italicized in that
>> text, an ISO convention identifying this sentence as the official
>> definition of that term. Nothing in that definition allow you to match
>> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
>> sequence. It's the corresponding members that have to have
>> layout-compatible types, and "struct base" and "int" don't.
>
> Damn. Need to think on this. what about something like:
> ________________
> struct object_0
> {
> int b; // common initial sequence
> int p0;
> };
>
> struct object_1
> {
> int b; // common initial sequence
> int p0;
> int p1;
> };
>
> union object
> {
> int b; // common initial sequence
> object_0 o0;
> object_1 o1;
> };
> ________________
>
> ? This gets rid of struct base.
The 'int b;' member of the union object isn't needed. Simply do this:
struct object_0 {
int b;
int p0;
};
struct object_1 {
int b;
int p0;
int p1;
};
union object {
object_0 o0;
object_1 o1;
};
To discriminate based on the "tag" field:
object something = ...;
if( something.o0.b == 0 ){ // the access to o0.b has to work
... // presumably o0 is the active member
} else if( something.o1.b == 1 ){ // the access to o1.b ALSO has to work
... // presumably o1 is the active member
}
Does that all make sense?
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-13 16:27 -0800 |
| Message-ID | <qvj1ts$4np$1@gioia.aioe.org> |
| In reply to | #71306 |
On 1/13/2020 8:57 AM, Tim Rentsch wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
>> On 1/12/2020 5:16 PM, James Kuyper wrote:
>>
>>> On 1/11/20 11:40 PM, Chris M. Thomasson wrote:
>>>
>>>> On 1/11/2020 7:28 AM, Tim Rentsch wrote:
>>>>
>>>>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>>>
>>> ...
>>>
>>>>>> #include <iostream>
>>>>>>
>>>>>> struct base
>>>>>> {
>>>>>> int p0;
>>>>>> };
>>>>>>
>>>>>> struct object_0
>>>>>> {
>>>>>> base b;
>>>>>> int p0;
>>>>>> };
>>>>>>
>>>>>> struct object_1
>>>>>> {
>>>>>> base b;
>>>>>> int p0;
>>>>>> int p1;
>>>>>> };
>>>>>>
>>>>>> union object
>>>>>> {
>>>>>> base b;
>>>>>> object_0 o0;
>>>>>> object_1 o1;
>>>>>> };
>>>>>>
>>>>>>
>>>>>> int main() {
>>>>>> object o;
>>>>>>
>>>>>> o.b.p0 = 41;
>>>>>> o.o0.b.p0 += 1;
>>>>>> o.o1.b.p0 += 1;
>>>>>>
>>>>>> // humm
>>>>>> int r = o.b.p0; // ub...
>>>>>>
>>>>>> std::cout << "r = " << r << "\n";
>>>>>>
>>>>>> return 0;
>>>>>> }
>>>>>> ___________________________
>>>>>>
>>>>>>
>>>>>> Wrt POD and a common base object on each sub-object in a union, well
>>>>>> does it bite the dust with UB?
>>>>>
>>>>> I believe this runs afoul of the rules for common initial
>>>>> sequences, because type 'base' has as its first member a type
>>>>> that is not layout compatible with the type of the first members
>>>>> of object_0 and object_1.
>>>>
>>>> Everything boils down to an int. Therefore, the common initial sequence
>>>> is an int. It should work. Its all POD, everything has that common int,
>>>> even in struct base. ...
>>>
>>> In a standard-layout union with an active member (9.5) of struct type
>>> T1, it is permitted to read a non-static data member m of another union
>>> member of struct type T2 provided m is part of the common initial
>>> sequence of T1 and T2." (9.2p19).
>>>
>>> "The common initial sequence of two standard-layout struct (Clause 9)
>>> types is the longest sequence of non-static data members and bit-fields
>>> in declaration order, starting with the first such entity in each of the
>>> structs, such that corresponding entities have layout-compatible types
>>> and either neither entity is a bit-field or both are bit-fields with the
>>> same width." (9.2p16). "common initial sequence" is italicized in that
>>> text, an ISO convention identifying this sentence as the official
>>> definition of that term. Nothing in that definition allow you to match
>>> up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
>>> sequence. It's the corresponding members that have to have
>>> layout-compatible types, and "struct base" and "int" don't.
>>
>> Damn. Need to think on this. what about something like:
>> ________________
>> struct object_0
>> {
>> int b; // common initial sequence
>> int p0;
>> };
>>
>> struct object_1
>> {
>> int b; // common initial sequence
>> int p0;
>> int p1;
>> };
>>
>> union object
>> {
>> int b; // common initial sequence
>> object_0 o0;
>> object_1 o1;
>> };
>> ________________
>>
>> ? This gets rid of struct base.
>
> The 'int b;' member of the union object isn't needed. Simply do this:
>
> struct object_0 {
> int b;
> int p0;
> };
>
> struct object_1 {
> int b;
> int p0;
> int p1;
> };
>
> union object {
> object_0 o0;
> object_1 o1;
> };
>
> To discriminate based on the "tag" field:
>
> object something = ...;
>
> if( something.o0.b == 0 ){ // the access to o0.b has to work
> ... // presumably o0 is the active member
> } else if( something.o1.b == 1 ){ // the access to o1.b ALSO has to work
> ... // presumably o1 is the active member
> }
>
> Does that all make sense?
>
Yes. I must of been thinking of some syntactic sugar wrt sticking the
base object in the union itself. As in, perform some function on o.o1
and read all of its "common" alterations from o.b. An out of many, one,
type of relationship. However, reading from o.o0.b, or o.o1.b provides
everything I need anyway for &(o.o0.b) == &(o.o1.b).
I added in the extraneous base in the union out of some sort of reflex
mixed with trying to just read from o.b.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-14 07:05 -0800 |
| Message-ID | <86muaqgjt6.fsf@linuxsc.com> |
| In reply to | #71325 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: [...] > I added in the extraneous base in the union out of some sort of > reflex mixed with trying to just read from o.b. Maybe you were thinking of programming in C. In C there is often benefit to have a "stub" type that serves mainly to differentiate the "concrete" types. AFAICT in C++ there is not, except perhaps as some sort of aid to the reader.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-14 20:58 -0800 |
| Message-ID | <qvm661$ieu$1@gioia.aioe.org> |
| In reply to | #71338 |
On 1/14/2020 7:05 AM, Tim Rentsch wrote:
> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
>
> [...]
>
>> I added in the extraneous base in the union out of some sort of
>> reflex mixed with trying to just read from o.b.
>
> Maybe you were thinking of programming in C.
I am a C programmer at heart. The funny part is that I removed the
struct keyword as in writing:
_____________________
struct object_0
{
base b;
int p0;
};
// instead of:
struct object_0
{
struct base b;
int p0;
};
_____________________
:^)
In C there is often
> benefit to have a "stub" type that serves mainly to differentiate
> the "concrete" types. AFAICT in C++ there is not, except perhaps
> as some sort of aid to the reader.
>
Interesting points to ponder. Actually, a decent chunk of my C++ work in
the past was wrapping up a C API. A lot of times the C API would be
wrapping up some externally assembled, assembly language.
For some reason, sometimes, when I created a pure C++ object, I would
code it up in C on my free time. Well, this was a habit wrt interfaces
that need to be exported in a shared lib. A nice clean C API is great
for this. C++ can have some issues wrt creating, say .so, or .dlls.
A C binding is okay with me.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-21 03:47 -0800 |
| Message-ID | <86eevtjajp.fsf@linuxsc.com> |
| In reply to | #71354 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > On 1/14/2020 7:05 AM, Tim Rentsch wrote: > >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> >> [...] >> >>> I added in the extraneous base in the union out of some sort of >>> reflex mixed with trying to just read from o.b. >> >> Maybe you were thinking of programming in C. > > I am a C programmer at heart. [example omitted] >> In C there is often benefit to have a "stub" type that serves >> mainly to differentiate the "concrete" types. AFAICT in C++ >> there is not, except perhaps as some sort of aid to the reader. I should elaborate on this. In C, if there is a union with several structs as members, it's okay to access a member in the common initial sequence of a struct actually in a union object, __given only a pointer to the struct__ (assuming the full definition of the union is visible). In C++, I believe the "common initial sequence" rule applies only when using the union type as part of the access expression. The C++ rule is a significantly weaker guarantee than the C rule. To me it seems to rob the feature of much of its value, even not counting the incongruity with the C rule. At this point there are so many differences between C and C++ that it seems inappropriate to say C is a subset of C++, even just mostly. > Interesting points to ponder. Actually, a decent chunk of my C++ > work in the past was wrapping up a C API. A lot of times the C API > would be wrapping up some externally assembled, assembly language. > > For some reason, sometimes, when I created a pure C++ object, I > would code it up in C on my free time. Well, this was a habit wrt > interfaces that need to be exported in a shared lib. A nice clean C > API is great for this. C++ can have some issues wrt creating, say > .so, or .dlls. > > A C binding is okay with me. Be warned: the different treatments, by C and by C++, of the union "special guarantee", might mean that calling through a C binding may result in undefined behavior in C++, even if the C code is well-defined by the C standard. It isn't clear to me what the implications of C++'s rules are in this area, and in particular whether a C++ implementation may be allowed to make some assumptions that would not be allowed under the C rules. I'm sorry I don't have any better advice to offer other than it would be wise to tread cautiously.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-15 01:22 -0800 |
| Message-ID | <ea1d06b8-8d42-4857-81c7-aa5987ade4e1@googlegroups.com> |
| In reply to | #71302 |
On Monday, 13 January 2020 03:28:10 UTC+2, Chris M. Thomasson wrote:
> On 1/12/2020 5:16 PM, James Kuyper wrote:
> > On 1/11/20 11:40 PM, Chris M. Thomasson wrote:
> >> On 1/11/2020 7:28 AM, Tim Rentsch wrote:
> >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes:
> > ...
> >>>> #include <iostream>
> >>>>
> >>>> struct base
> >>>> {
> >>>> int p0;
> >>>> };
> >>>>
> >>>> struct object_0
> >>>> {
> >>>> base b;
> >>>> int p0;
> >>>> };
> >>>>
> >>>> struct object_1
> >>>> {
> >>>> base b;
> >>>> int p0;
> >>>> int p1;
> >>>> };
> >>>>
> >>>> union object
> >>>> {
> >>>> base b;
> >>>> object_0 o0;
> >>>> object_1 o1;
> >>>> };
> >>>>
> >>>>
> >>>> int main() {
> >>>> object o;
> >>>>
> >>>> o.b.p0 = 41;
> >>>> o.o0.b.p0 += 1;
> >>>> o.o1.b.p0 += 1;
> >>>>
> >>>> // humm
> >>>> int r = o.b.p0; // ub...
> >>>>
> >>>> std::cout << "r = " << r << "\n";
> >>>>
> >>>> return 0;
> >>>> }
> >>>> ___________________________
> >>>>
> >>>>
> >>>> Wrt POD and a common base object on each sub-object in a union, well
> >>>> does it bite the dust with UB?
> >>>
> >>> I believe this runs afoul of the rules for common initial
> >>> sequences, because type 'base' has as its first member a type
> >>> that is not layout compatible with the type of the first members
> >>> of object_0 and object_1.
> >>
> >> Everything boils down to an int. Therefore, the common initial sequence
> >> is an int. It should work. Its all POD, everything has that common int,
> >> even in struct base. ...
> >
> > In a standard-layout union with an active member (9.5) of struct type
> > T1, it is permitted to read a non-static data member m of another union
> > member of struct type T2 provided m is part of the common initial
> > sequence of T1 and T2." (9.2p19).
> >
> > "The common initial sequence of two standard-layout struct (Clause 9)
> > types is the longest sequence of non-static data members and bit-fields
> > in declaration order, starting with the first such entity in each of the
> > structs, such that corresponding entities have layout-compatible types
> > and either neither entity is a bit-field or both are bit-fields with the
> > same width." (9.2p16). "common initial sequence" is italicized in that
> > text, an ISO convention identifying this sentence as the official
> > definition of that term. Nothing in that definition allow you to match
> > up o.b.p0 with o.o0.b.p0 in order to qualify as having a common initial
> > sequence. It's the corresponding members that have to have
> > layout-compatible types, and "struct base" and "int" don't.
>
> Damn. Need to think on this. what about something like:
> ________________
> struct object_0
> {
> int b; // common initial sequence
> int p0;
> };
>
> struct object_1
> {
> int b; // common initial sequence
> int p0;
> int p1;
> };
>
> union object
> {
> int b; // common initial sequence
> object_0 o0;
> object_1 o1;
> };
> ________________
Actually to get rid of the odd controversy you should go in the
other direction and add more bloat:
#include <iostream>
struct base
{
int p0;
};
struct object_0
{
base b;
int p0;
};
struct object_1
{
base b;
int p0;
int p1;
};
union object
{
struct X {base b;} x;
object_0 o0;
object_1 o1;
};
int main() {
object o;
o.x.b.p0 = 41;
o.o0.b.p0 += 1;
o.o1.b.p0 += 1;
// humm
int r = o.x.b.p0; // OK
std::cout << "r = " << r << "\n";
return 0;
}
There are no anonymous structs in C++ so only extensions
of certain compilers make it possible to rewrite in a way
that you can use "o.b.p0" instead of "o.x.b.p0".
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-15 08:04 -0500 |
| Message-ID | <qvn2ll$35k$1@dont-email.me> |
| In reply to | #71356 |
On 1/15/20 4:22 AM, Öö Tiib wrote:
...
> Actually to get rid of the odd controversy you should go in the
> other direction and add more bloat:
>
> #include <iostream>
>
> struct base
> {
> int p0;
> };
>
> struct object_0
> {
> base b;
> int p0;
> };
>
> struct object_1
> {
> base b;
> int p0;
> int p1;
> };
>
> union object
> {
> struct X {base b;} x;
Note: the "X" is unnecessary; struct tags are optional, and you have no
need for this one.
> object_0 o0;
> object_1 o1;
> };
>
>
> int main() {
> object o;
>
> o.x.b.p0 = 41;
Note: x is also unnecessary; you can simply use o.o0.b.p0 here.
> o.o0.b.p0 += 1;
> o.o1.b.p0 += 1;
>
> // humm
And also here:
> int r = o.x.b.p0; // OK
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-15 09:38 -0800 |
| Message-ID | <5388601c-62be-4ea6-9b4c-719a6bd2128b@googlegroups.com> |
| In reply to | #71357 |
On Wednesday, 15 January 2020 15:05:06 UTC+2, James Kuyper wrote:
> On 1/15/20 4:22 AM, Öö Tiib wrote:
> ...
> > Actually to get rid of the odd controversy you should go in the
> > other direction and add more bloat:
> >
> > #include <iostream>
> >
> > struct base
> > {
> > int p0;
> > };
> >
> > struct object_0
> > {
> > base b;
> > int p0;
> > };
> >
> > struct object_1
> > {
> > base b;
> > int p0;
> > int p1;
> > };
> >
> > union object
> > {
> > struct X {base b;} x;
>
> Note: the "X" is unnecessary; struct tags are optional, and you have no
> need for this one.
Unnecessary in C. In C++ it has been always needed and even C++20 does
not add anonymous structs.
>
> > object_0 o0;
> > object_1 o1;
> > };
> >
> >
> > int main() {
> > object o;
> >
> > o.x.b.p0 = 41;
>
> Note: x is also unnecessary; you can simply use o.o0.b.p0 here.
>
> > o.o0.b.p0 += 1;
> > o.o1.b.p0 += 1;
> >
> > // humm
>
> And also here:
>
> > int r = o.x.b.p0; // OK
You snipped my elaboration that: There are no anonymous structs in C++
so only extensions of certain compilers make it possible to rewrite
in a way that you can use "o.b.p0" instead of "o.x.b.p0".
Possibly you used a compiler with such extension and without
-pedantic option when trying it out.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-15 11:01 -0800 |
| Message-ID | <f29c8b6c-2f85-41b5-ab59-ce58af7bf003@googlegroups.com> |
| In reply to | #71359 |
> > > union object
> > > {
> > > struct X {base b;} x;
> >
> > Note: the "X" is unnecessary; struct tags are optional, and you have no
> > need for this one.
>
> Unnecessary in C. In C++ it has been always needed and even C++20 does
> not add anonymous structs.
That wouldn't be an anonymous struct, it would be an unnamed struct, and
C++ has always had them. "A class-specifier whose class-head omits the
class-head-name defines an unnamed class." (12p1).
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-13 08:37 -0800 |
| Message-ID | <86zhergvn7.fsf@linuxsc.com> |
| In reply to | #71300 |
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > On 1/11/2020 7:28 AM, Tim Rentsch wrote: > >> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >> >>> Is there some cryptic hidden thing in the standard that just might >>> "allow" for the following code to run without ub? >>> >>> [example removed] >> >> I believe this runs afoul of the rules for common initial >> sequences, because type 'base' has as its first member a type >> that is not layout compatible with the type of the first members >> of object_0 and object_1. > > Everything boils down to an int. Therefore, the common initial > sequence is an int. It should work. Its all POD, everything has that > common int, even in struct base. Afaict, The first int, in base, or > anything in union object has the same address. union object::b has the > same address as union object::o1::base. Its all POD. I see you have gotten some further guidance on this matter. I will respond further to your posting downstream.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2020-01-13 16:29 -0800 |
| Message-ID | <qvj20t$4np$2@gioia.aioe.org> |
| In reply to | #71305 |
On 1/13/2020 8:37 AM, Tim Rentsch wrote: > "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: > >> On 1/11/2020 7:28 AM, Tim Rentsch wrote: >> >>> "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> writes: >>> >>>> Is there some cryptic hidden thing in the standard that just might >>>> "allow" for the following code to run without ub? >>>> >>>> [example removed] >>> >>> I believe this runs afoul of the rules for common initial >>> sequences, because type 'base' has as its first member a type >>> that is not layout compatible with the type of the first members >>> of object_0 and object_1. >> >> Everything boils down to an int. Therefore, the common initial >> sequence is an int. It should work. Its all POD, everything has that >> common int, even in struct base. Afaict, The first int, in base, or >> anything in union object has the same address. union object::b has the >> same address as union object::o1::base. Its all POD. > > I see you have gotten some further guidance on this matter. > I will respond further to your posting downstream. > Thank you Tim. Indeed I have received some really interesting facts on the matter. Thank you, and all.
[toc] | [prev] | [standalone]
Page 7 of 7 — ← Prev page 1 2 3 4 5 6 [7]
Back to top | Article view | comp.lang.c++
csiph-web