Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #70446 > unrolled thread
| Started by | woodbrian77@gmail.com |
|---|---|
| First post | 2019-12-13 21:28 -0800 |
| Last post | 2019-12-15 09:49 +0000 |
| Articles | 20 on this page of 309 — 26 participants |
Back to article view | Back to comp.lang.c++
Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-13 21:28 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-14 09:23 +0000
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-14 17:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 09:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-14 12:00 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 13:51 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:19 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:13 -0800
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 15:35 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-14 22:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-14 16:03 -0800
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2019-12-15 15:41 +1300
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-14 22:55 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:53 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:18 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:44 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 20:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-15 15:11 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 23:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 15:41 -0800
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-16 05:18 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:46 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:57 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:21 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:37 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 15:13 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 14:12 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-17 19:35 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:14 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-17 08:32 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-18 16:26 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:11 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 11:23 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:31 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 19:56 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:42 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-19 20:26 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 09:25 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 04:35 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-20 16:28 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-20 10:36 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 16:33 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-21 17:22 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 10:18 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-21 21:21 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 14:30 -0800
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-22 21:36 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-22 15:05 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-22 17:03 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-22 17:46 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-22 18:07 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:23 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-23 16:33 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 16:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 18:51 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-23 17:02 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-23 19:17 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-24 09:49 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-24 02:16 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-25 00:30 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 09:46 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 16:38 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-26 17:33 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 19:52 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:14 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-27 09:41 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:05 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-28 21:01 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 09:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 12:21 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:30 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-29 21:45 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:10 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 14:03 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 12:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 04:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 13:01 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-30 15:17 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:22 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:49 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 17:18 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:12 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 18:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 18:38 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 19:17 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 20:55 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:01 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 13:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 14:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 14:12 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 15:39 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 15:45 +0100
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 15:22 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:16 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 17:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 17:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:21 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:35 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:51 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:59 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 12:23 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:14 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:52 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 18:58 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:00 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:21 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:22 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 18:46 +0100
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 20:30 +0200
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:44 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:10 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 13:03 +0100
Re: Don't be fooled by cpp.sh Ian Collins <ian-news@hotmail.com> - 2020-01-12 07:50 +1300
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-11 11:55 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-11 23:59 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:04 +0100
Re: Don't be fooled by cpp.sh Richard Damon <Richard@Damon-Family.org> - 2020-01-04 20:04 -0500
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-05 13:36 +0100
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-06 18:39 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:16 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-31 17:01 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 17:34 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:09 +0100
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 03:29 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-30 19:37 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 11:19 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:14 +0100
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-31 16:06 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 05:39 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:39 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:25 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 12:00 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:10 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-31 16:42 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:07 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-01 15:48 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:24 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 12:02 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 10:52 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-02 13:27 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 16:45 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2020-01-02 16:55 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 17:24 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-02 18:30 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 09:40 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 22:58 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:28 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:56 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-02 22:20 -0500
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-03 14:53 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-03 17:22 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:45 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 09:01 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-03 10:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-03 21:05 -0500
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:46 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-10 09:51 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:59 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 19:06 +0200
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-31 14:06 +0200
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 13:38 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 16:13 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-31 17:06 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:09 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-31 18:11 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:13 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-01 09:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:25 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-03 10:09 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-04 12:43 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-04 18:02 -0600
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-05 10:41 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 12:31 -0600
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-05 20:11 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2020-01-05 11:22 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-05 21:07 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-05 20:40 -0800
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2020-01-06 18:08 -0600
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-06 23:17 -0500
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:37 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-07 08:28 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 14:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-01 23:15 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:33 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2020-01-02 12:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:14 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-31 19:16 +0100
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-31 18:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-31 12:29 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-01 09:17 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-30 16:32 +0100
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-30 14:57 +0100
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-31 09:23 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-30 22:16 -0500
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:30 -0800
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:12 -0800
Re: Don't be fooled by cpp.sh Siri Cruise <chine.bleu@yahoo.com> - 2019-12-30 20:07 -0800
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 13:50 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2020-01-01 08:11 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2020-01-02 09:28 +0000
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 21:26 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-29 11:31 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-29 18:35 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-29 18:40 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-30 10:12 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:10 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 12:11 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-29 22:20 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-30 01:23 -0800
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 15:54 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-30 17:07 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 19:58 +0000
Re: Don't be fooled by cpp.sh Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2019-12-30 23:59 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-30 21:23 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-28 18:09 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibble@i42.removethisbit.co.uk> - 2019-12-26 18:30 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-27 17:17 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-27 09:58 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 12:06 +0000
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-28 08:39 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.org - 2019-12-28 16:57 +0000
Re: Don't be fooled by cpp.sh Pavel <pauldontspamtolk@removeyourself.dontspam.yahoo> - 2020-01-02 23:18 -0500
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-26 10:54 -0800
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-26 22:50 +0200
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-26 10:38 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-24 17:52 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-24 23:53 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-25 08:51 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-25 10:54 -0800
Re: Don't be fooled by cpp.sh woodbrian77@gmail.com - 2019-12-21 08:42 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-21 09:25 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:28 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-18 20:00 +0000
Re: Don't be fooled by cpp.sh Paavo Helde <myfirstname@osa.pri.ee> - 2019-12-18 22:12 +0200
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-19 08:47 +0000
Re: Don't be fooled by cpp.sh Bonita Montero <Bonita.Montero@gmail.com> - 2019-12-30 14:03 +0100
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 11:49 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 12:05 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-18 12:19 -0800
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-16 21:13 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-17 09:38 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-17 09:14 +0000
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-17 17:50 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:35 +0100
Re: Don't be fooled by cpp.sh Mr Flibble <flibbleREMOVETHISBIT@i42.co.uk> - 2019-12-15 20:48 +0000
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-16 09:55 +0000
Re: Don't be fooled by cpp.sh Melzzzzz <Melzzzzz@zzzzz.com> - 2019-12-15 11:12 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 06:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 16:48 +0000
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 09:10 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 18:33 +0000
Re: Don't be fooled by cpp.sh Jorgen Grahn <grahn+nntp@snipabacken.se> - 2019-12-15 19:29 +0000
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-15 23:38 -0500
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:23 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:36 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-15 21:43 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 09:44 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 12:10 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:21 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 10:54 -0600
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:47 -0800
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 11:19 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:15 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:23 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 09:31 +0100
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:23 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-16 21:45 +0000
Re: Don't be fooled by cpp.sh Robert Wessel <robertwessel2@yahoo.com> - 2019-12-16 23:20 -0600
Re: Don't be fooled by cpp.sh Vir Campestris <vir.campestris@invalid.invalid> - 2019-12-17 21:56 +0000
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 22:06 -0800
Re: Don't be fooled by cpp.sh "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2019-12-16 19:42 -0800
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 11:56 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:18 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-16 21:03 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 00:04 +0100
Re: Don't be fooled by cpp.sh Bart <bc@freeuk.com> - 2019-12-17 01:06 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 14:51 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:25 -0500
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 14:13 +0100
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 16:32 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 10:52 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 21:24 +0100
Re: Don't be fooled by cpp.sh Öö Tiib <ootiib@hot.ee> - 2019-12-16 10:56 -0800
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-16 20:45 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-16 22:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 04:07 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:00 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 14:44 +0000
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 15:54 +0100
Re: Don't be fooled by cpp.sh Ben Bacarisse <ben.usenet@bsb.me.uk> - 2019-12-17 15:52 +0000
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 11:51 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-17 22:10 +0100
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-17 22:08 -0800
Re: Don't be fooled by cpp.sh David Brown <david.brown@hesbynett.no> - 2019-12-18 08:56 +0100
Re: Don't be fooled by cpp.sh Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 08:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-17 23:55 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-18 09:36 -0800
Re: Don't be fooled by cpp.sh Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2019-12-16 22:29 -0800
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 22:40 -0500
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:17 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-15 21:24 -0800
Re: Don't be fooled by cpp.sh Bo Persson <bo@bo-persson.se> - 2019-12-16 12:13 +0100
Re: Don't be fooled by cpp.sh James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-12-16 07:44 -0500
Re: Don't be fooled by cpp.sh Daniel <danielaparker@gmail.com> - 2019-12-16 18:53 -0800
Re: Don't be fooled by cpp.sh boltar@nowhere.co.uk - 2019-12-15 09:49 +0000
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 10:52 +0000 |
| Message-ID | <quki1g$bab$1@gioia.aioe.org> |
| In reply to | #70958 |
On Thu, 02 Jan 2020 12:02:48 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 2.01.2020 11:24, boltar@nowhere.org wrote: >> Really? Please state exactly where I ever suggested using unions for classes >> rather than just POD. > >The rules are the same, whether the union contains PODS or non-PODS. The They might be the same but that doesn't mean using complex classes in unions is a good idea and I never advocated it. >> point of a union is to access MORE than 1 type without doing any sets in >> between. > >Something which is illegal by the standard cannot be "the point" of a >standard feature. Where is it stated thats its illegal? >>> Good that you are starting to understand it now. >> >> Perhaps you need to improve your English. > >And you need to improve your sarcasm detectors! Sarcasm doesn't work if YOU are the one who missed the point.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-02 13:27 +0200 |
| Message-ID | <qukk2l$m6c$1@dont-email.me> |
| In reply to | #70962 |
On 2.01.2020 12:52, boltar@nowhere.org wrote: > On Thu, 02 Jan 2020 12:02:48 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 2.01.2020 11:24, boltar@nowhere.org wrote: >>> Really? Please state exactly where I ever suggested using unions for classes >>> rather than just POD. >> >> The rules are the same, whether the union contains PODS or non-PODS. The > > They might be the same but that doesn't mean using complex classes in unions is > a good idea and I never advocated it. > >>> point of a union is to access MORE than 1 type without doing any sets in >>> between. >> >> Something which is illegal by the standard cannot be "the point" of a >> standard feature. > > Where is it stated thats its illegal? You see, I'm not against making the union type punning legal for POD types, for C compatibility, as proposed by Mr Flibble in another thread. If and when this gets incorporated into the C++ standard, I will happily encourage it as it is a bit safer than some other type punning methods (at least it gets the alignments correct). However, for now this is UB by the standard, and "illegal" is a colloquial term often used for UB in technical standards. I used this term because it seems you cannot really grasp what UB is. > >>>> Good that you are starting to understand it now. >>> >>> Perhaps you need to improve your English. >> >> And you need to improve your sarcasm detectors! > > Sarcasm doesn't work if YOU are the one who missed the point. Amusing...
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 16:45 +0000 |
| Message-ID | <qul6n8$1ebb$1@gioia.aioe.org> |
| In reply to | #70965 |
On Thu, 02 Jan 2020 13:27:15 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 2.01.2020 12:52, boltar@nowhere.org wrote: >>> Something which is illegal by the standard cannot be "the point" of a >>> standard feature. >> >> Where is it stated thats its illegal? > >You see, I'm not against making the union type punning legal for POD So its not stated anywhere then. >types, for C compatibility, as proposed by Mr Flibble in another thread. >If and when this gets incorporated into the C++ standard, I will happily If its not in the standard but is it in C then it gets incorporated into C++ unless stated otherwise. >encourage it as it is a bit safer than some other type punning methods >(at least it gets the alignments correct). > >However, for now this is UB by the standard, and "illegal" is a >colloquial term often used for UB in technical standards. I used this >term because it seems you cannot really grasp what UB is. I have no idea what UB stands for nor do I care.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2020-01-02 16:55 +0000 |
| Message-ID | <kgpPF.603042$O9t.212310@fx36.am4> |
| In reply to | #70972 |
On 2020-01-02, boltar@nowhere.org <boltar@nowhere.org> wrote: > On Thu, 02 Jan 2020 13:27:15 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >>On 2.01.2020 12:52, boltar@nowhere.org wrote: >>>> Something which is illegal by the standard cannot be "the point" of a >>>> standard feature. >>> >>> Where is it stated thats its illegal? >> >>You see, I'm not against making the union type punning legal for POD > > So its not stated anywhere then. > >>types, for C compatibility, as proposed by Mr Flibble in another thread. >>If and when this gets incorporated into the C++ standard, I will happily > > If its not in the standard but is it in C then it gets incorporated into > C++ unless stated otherwise. > >>encourage it as it is a bit safer than some other type punning methods >>(at least it gets the alignments correct). >> >>However, for now this is UB by the standard, and "illegal" is a >>colloquial term often used for UB in technical standards. I used this >>term because it seems you cannot really grasp what UB is. > > I have no idea what UB stands for nor do I care. UB is simply not guarranted to work as intended. > > -- press any key to continue or any other to quit... U ničemu ja ne uživam kao u svom statusu INVALIDA -- Zli Zec Svi smo svedoci - oko 3 godine intenzivne propagande je dovoljno da jedan narod poludi -- Zli Zec Na divljem zapadu i nije bilo tako puno nasilja, upravo zato jer su svi bili naoruzani. -- Mladen Gogala
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 17:24 +0000 |
| Message-ID | <qul90l$1p9b$1@gioia.aioe.org> |
| In reply to | #70973 |
On Thu, 02 Jan 2020 16:55:44 GMT Melzzzzz <Melzzzzz@zzzzz.com> wrote: >On 2020-01-02, boltar@nowhere.org <boltar@nowhere.org> wrote: >> On Thu, 02 Jan 2020 13:27:15 +0200 >> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>On 2.01.2020 12:52, boltar@nowhere.org wrote: >>>>> Something which is illegal by the standard cannot be "the point" of a >>>>> standard feature. >>>> >>>> Where is it stated thats its illegal? >>> >>>You see, I'm not against making the union type punning legal for POD >> >> So its not stated anywhere then. >> >>>types, for C compatibility, as proposed by Mr Flibble in another thread. >>>If and when this gets incorporated into the C++ standard, I will happily >> >> If its not in the standard but is it in C then it gets incorporated into >> C++ unless stated otherwise. >> >>>encourage it as it is a bit safer than some other type punning methods >>>(at least it gets the alignments correct). >>> >>>However, for now this is UB by the standard, and "illegal" is a >>>colloquial term often used for UB in technical standards. I used this >>>term because it seems you cannot really grasp what UB is. >> >> I have no idea what UB stands for nor do I care. > >UB is simply not guarranted to work as intended. Union behaviour is architecture specific anyway. You need to know what you're doing when you use them especially if writing cross platform code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-02 18:30 +0100 |
| Message-ID | <qul9ba$a2d$2@news.albasani.net> |
| In reply to | #70975 |
>> UB is simply not guarranted to work as intended. > Union behaviour is architecture specific anyway. When you have your own variant through a union by selectively constructing and destructing one of the subobjects of a union, the behaviour isn't architecture-specific.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-03 09:40 +0100 |
| Message-ID | <qumul0$m1n$1@dont-email.me> |
| In reply to | #70976 |
On 02/01/2020 18:30, Bonita Montero wrote: >>> UB is simply not guarranted to work as intended. > >> Union behaviour is architecture specific anyway. > > When you have your own variant through a union by selectively > constructing and destructing one of the subobjects of a union, > the behaviour isn't architecture-specific. True. Stick to behaviour fully defined in the standards, and you should be fine on any architecture. And the behaviour of ordinary unions is not architecture-specific either, as long as you are using the behaviour defined in the standards. Some aspects are implementation-dependent, as always (sizes, alignments, etc.). These are usually common for different implementations on the same architecture, but not necessarily. Any extensions - such as allowing type-punning by unions in C++ - is implementation dependent, not architecture dependent. In other words, it depends on the exact compiler and possibly the options used, not (just) the target architecture.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-02 22:58 +0100 |
| Message-ID | <qulp30$d0r$1@dont-email.me> |
| In reply to | #70972 |
On 02/01/2020 17:45, boltar@nowhere.org wrote: > On Thu, 02 Jan 2020 13:27:15 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 2.01.2020 12:52, boltar@nowhere.org wrote: >>>> Something which is illegal by the standard cannot be "the point" of a >>>> standard feature. >>> >>> Where is it stated thats its illegal? >> >> You see, I'm not against making the union type punning legal for POD > > So its not stated anywhere then. The C++ standards are notoriously difficult to read on this particular point. C11 makes it clear that type-punning via unions is allowed - the C++ standards have no equivalent note. They do say, however, that at most one (non-static) data member can be "active" at a time. Based on the rules for lifetimes and active members of a union, writing to one member of the union and reading from a different member is undefined behaviour. Also note that the C and C++ standards consider anything that is not explicitly described behaviour, to be undefined behaviour. So since there isn't anything describing this usage in C++, the behaviour is undefined by default - it simply hasn't been given a definition. > >> types, for C compatibility, as proposed by Mr Flibble in another thread. >> If and when this gets incorporated into the C++ standard, I will happily > > If its not in the standard but is it in C then it gets incorporated into > C++ unless stated otherwise. Absolute nonsense. C++ is not a superset of C. You will get many subtle things wrong if you keep thinking this way. > >> encourage it as it is a bit safer than some other type punning methods >> (at least it gets the alignments correct). >> >> However, for now this is UB by the standard, and "illegal" is a >> colloquial term often used for UB in technical standards. I used this >> term because it seems you cannot really grasp what UB is. > > I have no idea what UB stands for nor do I care. > It stands for "undefined behaviour" - something that does not have an effect or behaviour defined by the relevant standard. A particular compiler is always free to give a definition to the behaviour if it wants, but does not have to do so. Generally, you should avoid any kind of undefined behaviour in your code unless your compiler documents that it defines the particular point, and you are happy with code that is not portable. (There is nothing wrong with non-portable code, as long as you are aware of the issue.)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-02 22:28 -0500 |
| Message-ID | <qumcdo$9ui$1@dont-email.me> |
| In reply to | #70972 |
On 1/2/20 11:45 AM, boltar@nowhere.org wrote: > On Thu, 02 Jan 2020 13:27:15 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: ... >> However, for now this is UB by the standard, and "illegal" is a >> colloquial term often used for UB in technical standards. I used this >> term because it seems you cannot really grasp what UB is. > > I have no idea what UB stands for nor do I care. UB is a common abbreviation for "undefined behavior". The phrase “undefined behavior” is defined by the C++ standard as having the following meaning: “behavior for which this International Standard imposes no requirements” (3.27). This is the most seriously negative thing the C++ standard ever says about any C++ code. Any program that violates at least one diagnosable rule (that term is defined in 4.1p1), must result in the generation of at least one diagnostic message (4.1p2). An implementation is still free to create an executable program, and if you choose to execute it, the behavior of that program is undefined, but at least you get that diagnostic message. When the behavior is simply undefined, you may get no warning. This should scare you. If it does’t, you don’t properly understand what “no requirements” really means. It’s popular to explain what this means by giving a humorously outrageous example, such as “demons may pop out of your nose” or “nasal demons” for short. It’s fun coming up with examples, and I normally try to give a different example every time I explain this concept. Doing so is also useful, because the outrageusness of the example catches people’s attention and makes it easier to remember. It’s also literally true: there may be many reasons why it’s not possible for code with undefined behavior to cause demons to pop out of your nose (the non-existence of the demons being a prime example). However, a requirement imposed by the C++ standard is NOT one of those reasons. However, you strike me as the kind of person who wouldn’t appreciate the humor, and would let that lack of appreciation get in the way of correctly understanding what’s at stake. Therefore, I’ll explain the stakes in a much more boring fashion. When you write code with undefined behavior, you're not actually telling the implementation to do what you think you're telling it to do - you're telling it that you don't care what your code actually does when executed. That's something you should avoid telling the implementation, unless it's actually true. Is there anything, anything at all, that a program could be built to do when run on the platform where you will be running your program, that you absolutely don’t want your program to do? If you say “No”, there’s no problem. There’s also no need to compile your program, or even to write it. If you don’t care what your program does, then you can save yourself a lot of time and trouble by using any arbitrary program you can find that’s already been written and compiled. If you’re sane, however, you’ll answer “Yes” to that question. Well, when the behavior of your program is undefined, that means that a fully conforming implementation of C++ can take your source code, and translate it into an executable program that does whatever it is you most strongly wish it wouldn’t do. If that statement doesn’t scare you into avoiding undefined behavior, you really don’t understand the full depth of “no requirements’ – none – of any sort – whatsoever. There is an important loophole in this statement, however: it says “this international standard”. The behavior can be undefined as far as the C++ standard is concerned, and yet there could be some document other than the C++ standard which does impose requirements on the behavior. The only case where you should ever tolerate C++ code with undefined behavior is when you know three things: 1. There is a document somewhere that does guarantee the behavior of that code. 2. That document has authority that applies everywhere that you need it to apply. 3. What that document guarantees about the behavior matches what you want the behavior to be. So – do you want to claim an exemption based upon this loophole? Then please identify the document which provides the guarantee for the behavior of your code which the C++ standard fails to provide, and also identify the scope of the authority of that document, and finally identify what precisely that document guarantees about the behavior of your code. I doubt that you can.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-02 22:56 -0500 |
| Message-ID | <qume28$g53$1@dont-email.me> |
| In reply to | #70972 |
On 1/2/20 11:45 AM, boltar@nowhere.org wrote: ... > If its not in the standard but is it in C then it gets incorporated into > C++ unless stated otherwise. The only significant part of the C standard that was incorporated into the C++ standard by reference was the the C standard library. Section 17.2 says: "1 The C ++ standard library also makes available the facilities of the C standard library, suitably adjusted to ensure static type safety. 2 The descriptions of many library functions rely on the C standard library for the signatures and semantics of those functions. In all such cases, any use of the restrict qualifier shall be omitted." As far as the language itself is concerned, there is no corresponding clause. The C++ standard contains it's own specifications for everything, even for those features it shares with C, even when those specifications were explicitly written to match what the C standard says about the same feature. And when they don't say the same thing, that's deliberate.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-02 22:20 -0500 |
| Message-ID | <qumbtt$7jr$1@dont-email.me> |
| In reply to | #70962 |
On 1/2/20 5:52 AM, boltar@nowhere.org wrote: > On Thu, 02 Jan 2020 12:02:48 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 2.01.2020 11:24, boltar@nowhere.org wrote: >>> Really? Please state exactly where I ever suggested using unions for classes >>> rather than just POD. >> >> The rules are the same, whether the union contains PODS or non-PODS. The > > They might be the same but that doesn't mean using complex classes in unions is > a good idea and I never advocated it. They are the same, which does mean that if you're careful to follow the rules laid out in the standard, it's quite safe to use complex classes in unions. The relevant rules are: "A union can have member functions (including constructors and destructors), but it shall not have virtual (10.3) functions. A union shall not have base classes. A union shall not be used as a base class. If a union contains a non-static data member of reference type the program is ill-formed. [ Note: If any non-static data member of a union has a non-trivial default constructor (12.1), copy constructor (12.8), move constructor (12.8), copy assignment operator (12.8), move assignment operator (12.8), or destructor (12.4), the corresponding member function of the union must be user-provided or it will be implicitly deleted (8.4.3) for the union. — end note ]" (9.5p3). "[ Note: In general, one must use explicit destructor calls and placement new operators to change the active member of a union. — end note ]" (9.5p4). >>> point of a union is to access MORE than 1 type without doing any sets in >>> between. >> >> Something which is illegal by the standard cannot be "the point" of a >> standard feature. > > Where is it stated thats its illegal? "Undefined behavior may be expected when this International Standard omits any explicit definition of behavior" (1.3.25). "In a union, at most one of the non-static data members can be active at any time, that is, the value of at most one of the non-static data members can be stored in a union at any time." (9.5p1). If you can, please identify the standard's explicit definition of the behavior that occurs when you read from a different member of a union than the one currently active. There isn't one. As of C2011, there is one in non-normative text of the C standard, but there's no such definition in any version of the C++. That absence is rather odd, if you're going to insist that such behavior is the main reason for the existence of unions.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-03 14:53 +0000 |
| Message-ID | <qunkhr$hou$1@gioia.aioe.org> |
| In reply to | #70990 |
On Thu, 2 Jan 2020 22:20:28 -0500 James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >On 1/2/20 5:52 AM, boltar@nowhere.org wrote: >> On Thu, 02 Jan 2020 12:02:48 +0200 >> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>> Something which is illegal by the standard cannot be "the point" of a >>> standard feature. >> >> Where is it stated thats its illegal? > >"Undefined behavior may be expected when this International Standard >omits any explicit definition of behavior" (1.3.25). >"In a union, at most one of the non-static data members can be active at >any time, that is, the value of at most one of the non-static data >members can be stored in a union at any time." (9.5p1). >If you can, please identify the standard's explicit definition of the >behavior that occurs when you read from a different member of a union >than the one currently active. There isn't one. As of C2011, there is >one in non-normative text of the C standard, but there's no such >definition in any version of the C++. That absence is rather odd, if >you're going to insist that such behavior is the main reason for the >existence of unions. Not stated doesn't make it illegal. Its not stated anywhere that 1+1 = 2 anywhere in the standard either funnily enough.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-03 17:22 +0100 |
| Message-ID | <qunpnh$gpa$1@dont-email.me> |
| In reply to | #71018 |
On 03/01/2020 15:53, boltar@nowhere.org wrote: > On Thu, 2 Jan 2020 22:20:28 -0500 > James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >> On 1/2/20 5:52 AM, boltar@nowhere.org wrote: >>> On Thu, 02 Jan 2020 12:02:48 +0200 >>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>> Something which is illegal by the standard cannot be "the point" of a >>>> standard feature. >>> >>> Where is it stated thats its illegal? >> >> "Undefined behavior may be expected when this International Standard >> omits any explicit definition of behavior" (1.3.25). >> "In a union, at most one of the non-static data members can be active at >> any time, that is, the value of at most one of the non-static data >> members can be stored in a union at any time." (9.5p1). >> If you can, please identify the standard's explicit definition of the >> behavior that occurs when you read from a different member of a union >> than the one currently active. There isn't one. As of C2011, there is >> one in non-normative text of the C standard, but there's no such >> definition in any version of the C++. That absence is rather odd, if >> you're going to insist that such behavior is the main reason for the >> existence of unions. > > Not stated doesn't make it illegal. It makes it undefined behaviour. It's kind of obvious, really - if the behaviour has not been defined by the standards, it is undefined. > Its not stated anywhere that 1+1 = 2 > anywhere in the standard either funnily enough. > Actually, it is. Section 6.5.6p5 of the C standard says "The result of the binary + operator is the sum of the operands." There will be an equivalent definition in the C++ standard if you choose to look for it. At what point will you realise you'll benefit more by trying to learn from other people, rather than continually making a fool of yourself? You are ignorant of a great deal about how C++ works, in terms of the language, the standards, compilers, and practical usage. Fair enough - there is nothing wrong with ignorance (we are all ignorant about most things), and it is curable by listening, reading and learning. It is your insistence that you know what you are talking about that is the problem - as you get things wrong again, and again. Insulting people won't make you right - it just makes you appear more ridiculous.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-04 12:45 +0000 |
| Message-ID | <quq1d1$1611$1@gioia.aioe.org> |
| In reply to | #71032 |
On Fri, 3 Jan 2020 17:22:08 +0100 David Brown <david.brown@hesbynett.no> wrote: >On 03/01/2020 15:53, boltar@nowhere.org wrote: >> On Thu, 2 Jan 2020 22:20:28 -0500 >> James Kuyper <jameskuyper@alumni.caltech.edu> wrote: >>> On 1/2/20 5:52 AM, boltar@nowhere.org wrote: >>>> On Thu, 02 Jan 2020 12:02:48 +0200 >>>> Paavo Helde <myfirstname@osa.pri.ee> wrote: >>>>> Something which is illegal by the standard cannot be "the point" of a >>>>> standard feature. >>>> >>>> Where is it stated thats its illegal? >>> >>> "Undefined behavior may be expected when this International Standard >>> omits any explicit definition of behavior" (1.3.25). >>> "In a union, at most one of the non-static data members can be active at >>> any time, that is, the value of at most one of the non-static data >>> members can be stored in a union at any time." (9.5p1). >>> If you can, please identify the standard's explicit definition of the >>> behavior that occurs when you read from a different member of a union >>> than the one currently active. There isn't one. As of C2011, there is >>> one in non-normative text of the C standard, but there's no such >>> definition in any version of the C++. That absence is rather odd, if >>> you're going to insist that such behavior is the main reason for the >>> existence of unions. >> >> Not stated doesn't make it illegal. > >It makes it undefined behaviour. It's kind of obvious, really - if the >behaviour has not been defined by the standards, it is undefined. > >> Its not stated anywhere that 1+1 = 2 >> anywhere in the standard either funnily enough. >> > >Actually, it is. > >Section 6.5.6p5 of the C standard says "The result of the binary + >operator is the sum of the operands." There will be an equivalent Ok, you got me there. I genuinely didn't expect the bleeding obvious to be included in the standard but then I have better things to do with my time than read it. >definition in the C++ standard if you choose to look for it. > > >At what point will you realise you'll benefit more by trying to learn >from other people, rather than continually making a fool of yourself? Its such fun winding you all up :)
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-03 09:01 -0800 |
| Message-ID | <68359934-ade1-48cc-9055-5ccbc1371d64@googlegroups.com> |
| In reply to | #71018 |
Bonita Moreno said >[James Kuyper said (but was not properly > attributed)] > >"Undefined behavior may be expected when this International Standard > >omits any explicit definition of behavior" (1.3.25). > ... > > Not stated doesn't make it illegal. ... Correct, and I've said nothing to suggest otherwise. Nothing is illegal as far as the C++ standard is concerned. The absolute worst thing that the standard says about any code is "undefined behavior". The standard imposes no requirements on code with undefined behavior. In particular, it does not require that the author be jailed or fined (which is what it would mean to call it illegal). More importantly, it also doesn't require that the code be rejected, nor does it require that the user be warned. And, per 1.3.25, cited above, if "Not stated" qualifies as omission of any explicit definition of the behavior, then "Not stated" is, quite explicitly, sufficient to make the behavior undefined. > ... Its not stated anywhere that > 1+1 = 2 anywhere in the standard either funnily enough. True - but in this case the fact that it isn't stated does not mean that there's no explicit definition of the behavior. The explicit definition of the behavior doesn't have to be a complete list of every single case, and usually isn't. It can be, and usually is, a single general rule that happens to cover the specific case in question. In this case, there are two such rules: "The result of the binary + operator is the sum of the operands" (8.7p2) and "If two operands compare equal, the result is true for the == operator ... If the two operands compare false, the result is false for the == operator ..." (8.10p5). So - what general rule does the C++ standard state that covers the specific case if reading from a member of a union that is not currently the active one? Keep in mind that the relevant clause is says that "the value contained in the object indicated by the glvalue is the prvalue result." (7,1p3). The members of a union are considered to be distinct objects that happen to have the same location in memory. Therefore, if the member being read is not the active one, there is no value contained in that object, and 7.1p3 doesn't apply. The C standard contains a non-normative footnote which claims that the contents of that memory get reinterpreted as if they contained an object of the same type as the lvalue used to read it. The C++ committee has known about the C wording for more than two decades now, and has chosen to not incorporate similar wording in any version of the C++ standard. I think we can safely assume that this omission constitutes a deliberate difference between the two languages, probably due to the greater importance of type safety in C++. It's hard to imagine anything more type-unsafe than type punning.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-03 10:29 -0800 |
| Message-ID | <87sgkwo0ld.fsf@nosuchdomain.example.com> |
| In reply to | #71035 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes:
[...]
> So - what general rule does the C++ standard state that covers the
> specific case if reading from a member of a union that is not
> currently the active one?
> Keep in mind that the relevant clause is says that "the value
> contained in the object indicated by the glvalue is the prvalue
> result." (7,1p3). The members of a union are considered to be
> distinct objects that happen to have the same location in memory.
> Therefore, if the member being read is not the active one, there is
> no value contained in that object, and 7.1p3 doesn't apply.
> The C standard contains a non-normative footnote which claims that
> the contents of that memory get reinterpreted as if they contained an
> object of the same type as the lvalue used to read it. The C++
> committee has known about the C wording for more than two decades
> now, and has chosen to not incorporate similar wording in any version
> of the C++ standard. I think we can safely assume that this omission
> constitutes a deliberate difference between the two languages,
> probably due to the greater importance of type safety in C++. It's
> hard to imagine anything more type-unsafe than type punning.
That non-normative footnote does raise an interesting point, though.
N1570 (C11) 6.5.2.3 footnote 95:
If the member used to read the contents of a union object is
not the same as the member last used to store a value in the
object, the appropriate part of the object representation of
the value is reinterpreted as an object representation in the
new type as described in 6.2.6 (a process sometimes called
"type punning"). This might be a trap representation.
The Introduction to the C standard says:
Footnotes are provided to emphasize consequences of the rules
described in that subclause or elsewhere in this International
Standard.
So the footnote effectively asserts that its conclusions are implied
by normative rules, though it's not clear that there's any normative
text in the C standard that supports the claim in this footnote.
If the normative requirements in C++ are sufficiently similar to
those in C, one could argue that the assertion in that footnote is
as valid for C++ as for C.
(My own conclusion is that the lack of supporting normative text is a
flaw in the C standard. It should make a clear normative statement
about the behavior of type punning using union members.)
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-01-03 21:05 -0500 |
| Message-ID | <quorsi$k5v$1@dont-email.me> |
| In reply to | #71040 |
On 1/3/20 1:29 PM, Keith Thompson wrote: ... > (My own conclusion is that the lack of supporting normative text is a > flaw in the C standard. It should make a clear normative statement > about the behavior of type punning using union members.) Agreed.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 08:46 -0800 |
| Message-ID | <86o8vb45v5.fsf@linuxsc.com> |
| In reply to | #71040 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > [...] > >> So - what general rule does the C++ standard state that covers the >> specific case if reading from a member of a union that is not >> currently the active one? >> Keep in mind that the relevant clause is says that "the value >> contained in the object indicated by the glvalue is the prvalue >> result." (7,1p3). The members of a union are considered to be >> distinct objects that happen to have the same location in memory. >> Therefore, if the member being read is not the active one, there is >> no value contained in that object, and 7.1p3 doesn't apply. >> The C standard contains a non-normative footnote which claims that >> the contents of that memory get reinterpreted as if they contained an >> object of the same type as the lvalue used to read it. The C++ >> committee has known about the C wording for more than two decades >> now, and has chosen to not incorporate similar wording in any version >> of the C++ standard. I think we can safely assume that this omission >> constitutes a deliberate difference between the two languages, >> probably due to the greater importance of type safety in C++. It's >> hard to imagine anything more type-unsafe than type punning. > > That non-normative footnote does raise an interesting point, though. > > N1570 (C11) 6.5.2.3 footnote 95: > > If the member used to read the contents of a union object is > not the same as the member last used to store a value in the > object, the appropriate part of the object representation of > the value is reinterpreted as an object representation in the > new type as described in 6.2.6 (a process sometimes called > "type punning"). This might be a trap representation. > > The Introduction to the C standard says: > > Footnotes are provided to emphasize consequences of the rules > described in that subclause or elsewhere in this International > Standard. > > So the footnote effectively asserts that its conclusions are implied > by normative rules, though it's not clear that there's any normative > text in the C standard that supports the claim in this footnote. In my reading of the C standard, there is normative text that establishes the assertion in the footnote. > If the normative requirements in C++ are sufficiently similar to > those in C, one could argue that the assertion in that footnote is > as valid for C++ as for C. The C++ standard clearly does not admit the same reasoning as the C standard in this regard, because the definedness of accessing union members is tied (in C++) to their lifetimes, and the lifetimes are not the same in C++ as they are in C. In C++, the "UB-ness" of accessing a different union member can be established constructively (ie, it is not just a question of a definition being omitted). > (My own conclusion is that the lack of supporting normative text is a > flaw in the C standard. It should make a clear normative statement > about the behavior of type punning using union members.) There is normative text that implies what the footnote says. That isn't as obvious as some people might like, so it would be good if the behavior were described more directly, for clarity. But the behavior is described more directly: it is described in this very footnote.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-10 09:51 -0800 |
| Message-ID | <87y2ufjj2u.fsf@nosuchdomain.example.com> |
| In reply to | #71263 |
Tim Rentsch <tr.17687@z991.linuxsc.com> writes:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
[...]
>> That non-normative footnote does raise an interesting point, though.
>>
>> N1570 (C11) 6.5.2.3 footnote 95:
>>
>> If the member used to read the contents of a union object is
>> not the same as the member last used to store a value in the
>> object, the appropriate part of the object representation of
>> the value is reinterpreted as an object representation in the
>> new type as described in 6.2.6 (a process sometimes called
>> "type punning"). This might be a trap representation.
>>
>> The Introduction to the C standard says:
>>
>> Footnotes are provided to emphasize consequences of the rules
>> described in that subclause or elsewhere in this International
>> Standard.
>>
>> So the footnote effectively asserts that its conclusions are implied
>> by normative rules, though it's not clear that there's any normative
>> text in the C standard that supports the claim in this footnote.
>
> In my reading of the C standard, there is normative text that
> establishes the assertion in the footnote.
Do you have some reason for not telling us where that normative
text is? I know this is comp.lang.c++, but I suggest that the
presence of such text in the C standard, and its absence in the C++
standard, is relevant to C++.
>> If the normative requirements in C++ are sufficiently similar to
>> those in C, one could argue that the assertion in that footnote is
>> as valid for C++ as for C.
>
> The C++ standard clearly does not admit the same reasoning as the
> C standard in this regard, because the definedness of accessing
> union members is tied (in C++) to their lifetimes, and the
> lifetimes are not the same in C++ as they are in C. In C++, the
> "UB-ness" of accessing a different union member can be established
> constructively (ie, it is not just a question of a definition
> being omitted).
Please consider telling us *how* it can be established constructively
rather than just being vague.
[...]
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
[Note updated email address]
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 14:59 -0800 |
| Message-ID | <867e1y534z.fsf@linuxsc.com> |
| In reply to | #71264 |
Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > Tim Rentsch <tr.17687@z991.linuxsc.com> writes: > >> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes: > > [...] > >>> That non-normative footnote does raise an interesting point, though. >>> >>> N1570 (C11) 6.5.2.3 footnote 95: >>> >>> If the member used to read the contents of a union object is >>> not the same as the member last used to store a value in the >>> object, the appropriate part of the object representation of >>> the value is reinterpreted as an object representation in the >>> new type as described in 6.2.6 (a process sometimes called >>> "type punning"). This might be a trap representation. >>> >>> The Introduction to the C standard says: >>> >>> Footnotes are provided to emphasize consequences of the rules >>> described in that subclause or elsewhere in this International >>> Standard. >>> >>> So the footnote effectively asserts that its conclusions are implied >>> by normative rules, though it's not clear that there's any normative >>> text in the C standard that supports the claim in this footnote. >> >> In my reading of the C standard, there is normative text that >> establishes the assertion in the footnote. > > Do you have some reason for not telling us where that normative > text is? I know this is comp.lang.c++, but I suggest that the > presence of such text in the C standard, and its absence in the C++ > standard, is relevant to C++. I didn't have time for a longer posting. Also I don't think it's relevant for C++ because there is additional text in the C++ standard that explicitly makes such accesses be undefined behavior. >>> If the normative requirements in C++ are sufficiently similar to >>> those in C, one could argue that the assertion in that footnote is >>> as valid for C++ as for C. >> >> The C++ standard clearly does not admit the same reasoning as the >> C standard in this regard, because the definedness of accessing >> union members is tied (in C++) to their lifetimes, and the >> lifetimes are not the same in C++ as they are in C. In C++, the >> "UB-ness" of accessing a different union member can be established >> constructively (ie, it is not just a question of a definition >> being omitted). > > Please consider telling us *how* it can be established constructively > rather than just being vague. My comments were consciously incomplete, but I don't think it's fair to call them vague, just incomplete. In any case I will try to post a more complete explanation sometime soon, in comp.lang.c.
[toc] | [prev] | [next] | [standalone]
Page 8 of 16 — ← Prev page 1 … 6 7 [8] 9 10 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web