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 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-06 18:39 +0000 |
| Message-ID | <slrnr16vn9.9in.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71124 |
On Sun, 2020-01-05, Richard Damon wrote: > On 12/31/19 12:46 PM, Bonita Montero wrote: ... >> -Wunused-function >> This would be disturbing if you would have the function in the >> code for a later purpose. > > Warning is early code development may not be that hard. Adding > #if 0 > #endif > > to 'remove' the function isn't that hard. That one is one of the warnings I /like/ to see during development, as a reminder of work that's still remaining. Commenting the function out would, for me, be pointless. Although, since I tend to work top--down, a more realistic such warning would be "foo declared static but not defined", when I write code which uses a function I haven't implemented yet. And of course linker errors in similar cases. /Jorgen -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-31 16:16 -0800 |
| Message-ID | <qugocg$12ng$2@gioia.aioe.org> |
| In reply to | #70881 |
On 12/31/2019 8:58 AM, Paavo Helde wrote: > On 31.12.2019 16:45, Bonita Montero wrote: > >> And no one uses -Wall practically because >> it generates a lot of nonsense-warnings > > Are you kidding? -Wall is one of the most basic options one always uses > with gcc (together with -Wextra and a bunch of other warning flags). Heck, what about -ansi and/or -pedantic... ;^) > >> and most libraries will not >> compile without a imense number of warnings. > > Maybe you are using a lot of sub-par libraries? > > >
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-31 17:01 -0800 |
| Message-ID | <251174e8-b121-492f-a057-5e2bfcf6dd43@googlegroups.com> |
| In reply to | #70913 |
On Wednesday, 1 January 2020 02:16:26 UTC+2, Chris M. Thomasson wrote: > On 12/31/2019 8:58 AM, Paavo Helde wrote: > > On 31.12.2019 16:45, Bonita Montero wrote: > > > >> And no one uses -Wall practically because > >> it generates a lot of nonsense-warnings > > > > Are you kidding? -Wall is one of the most basic options one always uses > > with gcc (together with -Wextra and a bunch of other warning flags). > > Heck, what about -ansi and/or -pedantic... ;^) Examples that one posts are good idea to try with -Wall -Wextra -pedantic or to explicitly tell with what options those have or haven't been tried. Everybody do typos, best of us at rate 0.1 per line and so it reduces confusion in communications. or
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-01 17:34 +0200 |
| Message-ID | <quie6h$ouj$1@dont-email.me> |
| In reply to | #70913 |
On 1.01.2020 2:16, Chris M. Thomasson wrote: > On 12/31/2019 8:58 AM, Paavo Helde wrote: >> On 31.12.2019 16:45, Bonita Montero wrote: >> >>> And no one uses -Wall practically because >>> it generates a lot of nonsense-warnings >> >> Are you kidding? -Wall is one of the most basic options one always >> uses with gcc (together with -Wextra and a bunch of other warning flags). > > Heck, what about -ansi and/or -pedantic... ;^) -ansi is a synonym for -std=c++98, this is too old. Suggesting at least -std=c++11. -pedantic is likely a good idea.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-01 23:09 +0100 |
| Message-ID | <quj5bn$2vg$1@dont-email.me> |
| In reply to | #70913 |
On 01/01/2020 01:16, Chris M. Thomasson wrote: > On 12/31/2019 8:58 AM, Paavo Helde wrote: >> On 31.12.2019 16:45, Bonita Montero wrote: >> >>> And no one uses -Wall practically because >>> it generates a lot of nonsense-warnings >> >> Are you kidding? -Wall is one of the most basic options one always >> uses with gcc (together with -Wextra and a bunch of other warning flags). > > Heck, what about -ansi and/or -pedantic... ;^) > Don't use "-ansi" - it is a misnomer. Use the "-std" option of your choice. I would always recommend using "-std". If you are writing highly portable code, then "-Wpedantic" along with a suitable choice of "-std" is recommended. But not all code is supposed to be highly portable. If you are writing code with the intention of using only gcc, then there is no problem using "-std=gnu++17", or whatever you want, and using gcc extensions. It won't be standard C++, but you can take advantage of the extensions provided - this is your choice when you write your code. (There are many other commonly used options, like "-O2" or "-o" to give the output file name. But -Wall is still a very commonly used standard option.) >> >>> and most libraries will not >>> compile without a imense number of warnings. >> >> Maybe you are using a lot of sub-par libraries? >> >> >> >
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 03:29 +0100 |
| Message-ID | <quebpu$8da$1@news.albasani.net> |
| In reply to | #70836 |
> Typically, simple test code will generate the > results you think - but in more complex situations where code gets > shuffled around, inlined, cloned, and otherwise manipulated, there > will be occasions where the compiler can generate tighter code on > the assumption that types like "int" and "float" never share the > same address. ... No, that won't happen. The compiler sees in my case that I alias a float as an unsigned and doesn't do any optimization around that.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-30 19:37 -0800 |
| Message-ID | <quefou$ni8$1@gioia.aioe.org> |
| In reply to | #70830 |
On 12/30/2019 9:12 AM, David Brown wrote:
[...]
> Don't mess with changing types
> through pointer (or, equivalently, reference) casting - it is undefined
> behaviour and many compilers (including gcc, clang and msvc) /will/ make
> you suffer for such language abuse.
>
>> But that's pure theory.
>
I must be missing your main point, however there is a nice case where
casting is "okay"?:
________________________
#include <iostream>
struct foo
{
int a;
};
struct bar
{
foo f;
int b;
};
int main() {
bar b = { { 0 }, 1};
foo* f = (struct foo*)&b;
f->a += 1;
b.b += 1;
std::cout << "b.f.a = " << b.f.a << "\n";
std::cout << "b.b = " << b.b << "\n";
return 0;
}
________________________
All pod, and perfectly fine to cast a pointer to a struct bar into a
pointer to a struct foo.
struct foo is the _first_ member of struct bar.
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2019-12-31 11:19 +0000 |
| Message-ID | <20191231111917.71e2d73f0e56ee812ed6ea1f@cvine--nospam--.freeserve.co.uk> |
| In reply to | #70847 |
On Mon, 30 Dec 2019 19:37:05 -0800
"Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> wrote:
> On 12/30/2019 9:12 AM, David Brown wrote:
> [...]
>
> > Don't mess with changing types
> > through pointer (or, equivalently, reference) casting - it is undefined
> > behaviour and many compilers (including gcc, clang and msvc) /will/ make
> > you suffer for such language abuse.
>
> I must be missing your main point, however there is a nice case where
> casting is "okay"?:
> ________________________
> #include <iostream>
>
> struct foo
> {
> int a;
> };
>
>
> struct bar
> {
> foo f;
> int b;
> };
>
>
> int main() {
> bar b = { { 0 }, 1};
> foo* f = (struct foo*)&b;
>
> f->a += 1;
> b.b += 1;
>
> std::cout << "b.f.a = " << b.f.a << "\n";
> std::cout << "b.b = " << b.b << "\n";
>
> return 0;
> }
> ________________________
>
> All pod, and perfectly fine to cast a pointer to a struct bar into a
> pointer to a struct foo.
>
> struct foo is the _first_ member of struct bar.
The point being made was I think about type punning, which leads to
trouble with C and C++'s strict aliasing rules.
There is no type punning in your code. It so happens that the address
of a standard-layout struct has two dynamic types (in C, effective
types): that of the struct and that of its first member, and so on
recursively if the first member is also a standard-layout struct. You
can freely cast between these and freely dereference the result, without
breaking strict aliasing, because a constructed object of the
dereferenced type will actually exist at the address in question: this
has always been the case in C++, but C++17 introduced a new term
"pointer-interconvertible"[1] to cover this.
Chris
[1] According to C++17 "If two objects are pointer-interconvertible,
then they have the same address, and it is possible to obtain a pointer
to one from a pointer to the other via a reinterpret_cast".
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 13:14 +0100 |
| Message-ID | <qufe30$pd7$1@dont-email.me> |
| In reply to | #70847 |
On 31/12/2019 04:37, Chris M. Thomasson wrote:
> On 12/30/2019 9:12 AM, David Brown wrote:
> [...]
>
>> Don't mess with changing types
>> through pointer (or, equivalently, reference) casting - it is undefined
>> behaviour and many compilers (including gcc, clang and msvc) /will/ make
>> you suffer for such language abuse.
>>
>>> But that's pure theory.
>>
>
> I must be missing your main point, however there is a nice case where
> casting is "okay"?:
> ________________________
> #include <iostream>
>
> struct foo
> {
> int a;
> };
>
>
> struct bar
> {
> foo f;
> int b;
> };
>
>
> int main() {
> bar b = { { 0 }, 1};
> foo* f = (struct foo*)&b;
>
> f->a += 1;
> b.b += 1;
>
> std::cout << "b.f.a = " << b.f.a << "\n";
> std::cout << "b.b = " << b.b << "\n";
>
> return 0;
> }
> ________________________
>
> All pod, and perfectly fine to cast a pointer to a struct bar into a
> pointer to a struct foo.
>
> struct foo is the _first_ member of struct bar.
The cast is fine - often when dealing with these things, the cast itself
is perfectly valid. It is accessing data through the cast result that
is in question.
And in this case, I believe it is perfectly valid - the address of a
struct is guaranteed (in C, and I think also in C++ for POD with no
virtual stuff) to be the address of its first member.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-31 16:06 -0800 |
| Message-ID | <qugnq9$11rm$1@gioia.aioe.org> |
| In reply to | #70861 |
On 12/31/2019 4:14 AM, David Brown wrote:
> On 31/12/2019 04:37, Chris M. Thomasson wrote:
>> On 12/30/2019 9:12 AM, David Brown wrote:
>> [...]
>>
>>> Don't mess with changing types
>>> through pointer (or, equivalently, reference) casting - it is undefined
>>> behaviour and many compilers (including gcc, clang and msvc) /will/ make
>>> you suffer for such language abuse.
>>>
>>>> But that's pure theory.
>>>
>>
>> I must be missing your main point, however there is a nice case where
>> casting is "okay"?:
>> ________________________
[...]
>> struct foo
>> {
>> int a;
>> };
[...]
>> ________________________
>>
>> All pod, and perfectly fine to cast a pointer to a struct bar into a
>> pointer to a struct foo.
>>
>> struct foo is the _first_ member of struct bar.
>
> The cast is fine - often when dealing with these things, the cast itself
> is perfectly valid. It is accessing data through the cast result that
> is in question.
>
> And in this case, I believe it is perfectly valid - the address of a
> struct is guaranteed (in C, and I think also in C++ for POD with no
> virtual stuff) to be the address of its first member.
>
Agreed. Thanks David. Fwiw, perhaps:
https://en.cppreference.com/w/cpp/types/is_pod
can come in handy... ;^)
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-30 05:39 -0800 |
| Message-ID | <5aba7ff5-15fe-4136-abc8-c9e81fb988eb@googlegroups.com> |
| In reply to | #70814 |
On Monday, 30 December 2019 15:01:52 UTC+2, bol...@nowhere.org wrote:
> On Mon, 30 Dec 2019 04:39:41 -0800 (PST)
> =?UTF-8?B?w5bDtiBUaWli?= <ootiib@hot.ee> wrote:
> >On Monday, 30 December 2019 14:18:05 UTC+2, bol...@nowhere.org wrote:
> >> On Mon, 30 Dec 2019 14:03:18 +0200
> >> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >> >On 30.12.2019 12:10, boltar@nowhere.org wrote:
> >> >> On Sun, 29 Dec 2019 21:45:14 +0200
> >> >> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >> >>> On 29.12.2019 20:30, boltar@nowhere.org wrote:
> >> >>>> On Sun, 29 Dec 2019 12:21:33 +0200
> >> >>>> Paavo Helde <myfirstname@osa.pri.ee> wrote:
> >> >>>>> On 29.12.2019 11:00, boltar@nowhere.org wrote:
> >> >>>>>
> >> >>>>>> The whole point of C unions is that they're NOT type safe. A type safe
> >
> >> >>> union
> >> >>>>>> is a contradiction.
> >> >>>>>
> >> >>>>> In case you haven't noticed yet we are talking C++ here, not C. A major
> >
> >> >>>>> strength of C++ is to build higher level abstractions, in particular
> >> >>>>> typesafe and zero overhead abstractions over low-level unsafe
> >primitives
> >> >>>>> like C unions.
> >> >>>>
> >> >>>> The whole point of a union is not to save memory, its to write as one
> >type
> >> >>>> and read as another ,
> >> >>>
> >> >>> You wish. However, this is undefined behavior by the standard.
> >> >>
> >> >> Oh dear, someone better tell the authors of the standard unix networking
> >> >> libraries then. Clearly they have no clue, I mean look at this horror from
> >
> >> >> net/if.h:
> >> >
> >> >There is no problem with unions when they are used correctly. This means
> >> >one can only read the union member which was written last. I am sure
> >>
> >> Complete rubbish. The point of a union is to write as one thing and read as
> >> another otherwise there is NO point in using a union since saving a few bytes
> >
> >> of memory is utterly irrelevant in the 21st century unless doing PIC or other
> >
> >> embedded programming.
> >
> >So the example you brought was meant to be used like that? Let me quote:
>
> Translation: "Oh, your 2nd example blew my argument out of the water, let me
> quickly backpedal a bit and try and catch you out with the 1st one"
What argument of mine? Cite where I claimed that unions are never used for
type punning in C. I know these are. That simply isn't topical about C++.
Your claim was "The whole point of a union is not to save memory, its to write
as one type and read as another" despite it has been always illegal by
intention and word of C++ standard. As proof of that claim you brought
that example:
>
> >
> >"union {
> > struct sockaddr ifru_addr;
> > struct sockaddr ifru_dstaddr;
> > struct sockaddr ifru_broadaddr;
> > short ifru_flags;
> > int ifru_metric;
> > int ifru_mtu;
> > int ifru_phys;
> > int ifru_media;
> > int ifru_intval;
> > caddr_t ifru_data;
> >
> >etc etc etc."
> >
> >Show me where they write into ifru_data and read from fru_broadaddr. :D
>
> You wouldn't , its a pointer not an array. But you would read from the addr
> structures interchangably.
We can since those are of same type but that isn't done since
the point of that union is that if type of ifru_dstaddr and
ifru_broadaddr become different after future maintenance then
it continues to work like it did.
So why you brought example that trashes your argument? :D
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-30 16:39 +0100 |
| Message-ID | <qud5mn$r6t$1@dont-email.me> |
| In reply to | #70814 |
On 30/12/2019 14:01, boltar@nowhere.org wrote:
>
> Want a better example? From math.h:
>
> __header_always_inline int __inline_signbitf(float __x) {
> union { float __f; unsigned int __u; } __u;
> __u.__f = __x;
> return (int)(__u.__u >> 31);
> }
>
I don't think anyone will disagree that unions are /sometimes/ used for
type-punning in C.
But when you claim that this is the /only/ use, outside tiny embedded
systems, you are talking drivel.
Type-punning through unions is not defined in standard C++. Some
compilers define its behaviour, but the standards don't - so you don't
use that in portable code. (Note that headers like <math.h> are most
certainly not intended to be portable, and can use any compiler-specific
features they want.)
Type-punning through unions is defined in C standards, but referencing
examples from its use in C says nothing about unions in C++.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2019-12-31 09:25 +0000 |
| Message-ID | <quf477$1gmv$1@gioia.aioe.org> |
| In reply to | #70823 |
On Mon, 30 Dec 2019 16:39:03 +0100
David Brown <david.brown@hesbynett.no> wrote:
>On 30/12/2019 14:01, boltar@nowhere.org wrote:
>
>>
>> Want a better example? From math.h:
>>
>> __header_always_inline int __inline_signbitf(float __x) {
>> union { float __f; unsigned int __u; } __u;
>> __u.__f = __x;
>> return (int)(__u.__u >> 31);
>> }
>>
>
>I don't think anyone will disagree that unions are /sometimes/ used for
>type-punning in C.
>
>But when you claim that this is the /only/ use, outside tiny embedded
>systems, you are talking drivel.
So other than the VERY occasional uses of saving memory or reducing the amount
pushed onto a stack in a function call/return, what would you say is the main
use for a union then?
>Type-punning through unions is defined in C standards, but referencing
>examples from its use in C says nothing about unions in C++.
Many C header files and source code will be included into a C++ project. In
any sane world C++ *will* support the same union rules as C because it has
to regardless of whatever the standards committee in their ivory tower say.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-12-31 12:00 +0000 |
| Message-ID | <BLGOF.675924$kBJ1.108590@fx12.am4> |
| In reply to | #70854 |
On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote:
> On Mon, 30 Dec 2019 16:39:03 +0100
> David Brown <david.brown@hesbynett.no> wrote:
>>On 30/12/2019 14:01, boltar@nowhere.org wrote:
>>
>>>
>>> Want a better example? From math.h:
>>>
>>> __header_always_inline int __inline_signbitf(float __x) {
>>> union { float __f; unsigned int __u; } __u;
>>> __u.__f = __x;
>>> return (int)(__u.__u >> 31);
>>> }
>>>
>>
>>I don't think anyone will disagree that unions are /sometimes/ used for
>>type-punning in C.
>>
>>But when you claim that this is the /only/ use, outside tiny embedded
>>systems, you are talking drivel.
>
> So other than the VERY occasional uses of saving memory or reducing the amount
> pushed onto a stack in a function call/return, what would you say is the main
> use for a union then?
In C++11 you can use objects in union....
>
>>Type-punning through unions is defined in C standards, but referencing
>>examples from its use in C says nothing about unions in C++.
>
> Many C header files and source code will be included into a C++ project. In
> any sane world C++ *will* support the same union rules as C because it has
> to regardless of whatever the standards committee in their ivory tower say.
Depends on compiler...
>
--
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 | 2019-12-31 16:10 +0000 |
| Message-ID | <qufru8$10cp$1@gioia.aioe.org> |
| In reply to | #70856 |
On Tue, 31 Dec 2019 12:00:33 GMT
Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote:
>> On Mon, 30 Dec 2019 16:39:03 +0100
>> David Brown <david.brown@hesbynett.no> wrote:
>>>On 30/12/2019 14:01, boltar@nowhere.org wrote:
>>>
>>>>
>>>> Want a better example? From math.h:
>>>>
>>>> __header_always_inline int __inline_signbitf(float __x) {
>>>> union { float __f; unsigned int __u; } __u;
>>>> __u.__f = __x;
>>>> return (int)(__u.__u >> 31);
>>>> }
>>>>
>>>
>>>I don't think anyone will disagree that unions are /sometimes/ used for
>>>type-punning in C.
>>>
>>>But when you claim that this is the /only/ use, outside tiny embedded
>>>systems, you are talking drivel.
>>
>> So other than the VERY occasional uses of saving memory or reducing the
>amount
>> pushed onto a stack in a function call/return, what would you say is the main
>
>> use for a union then?
>
>In C++11 you can use objects in union....
Possibly not a good idea if a virtual function table is anywhere in that
object. Otherwise it would be no different to a C struct.
>> Many C header files and source code will be included into a C++ project. In
>> any sane world C++ *will* support the same union rules as C because it has
>> to regardless of whatever the standards committee in their ivory tower say.
>
>Depends on compiler...
Name one compiler that doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Melzzzzz <Melzzzzz@zzzzz.com> |
|---|---|
| Date | 2019-12-31 16:42 +0000 |
| Message-ID | <WTKOF.101870$cY7.48582@fx39.am4> |
| In reply to | #70873 |
On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote:
> On Tue, 31 Dec 2019 12:00:33 GMT
> Melzzzzz <Melzzzzz@zzzzz.com> wrote:
>>On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote:
>>> On Mon, 30 Dec 2019 16:39:03 +0100
>>> David Brown <david.brown@hesbynett.no> wrote:
>>>>On 30/12/2019 14:01, boltar@nowhere.org wrote:
>>>>
>>>>>
>>>>> Want a better example? From math.h:
>>>>>
>>>>> __header_always_inline int __inline_signbitf(float __x) {
>>>>> union { float __f; unsigned int __u; } __u;
>>>>> __u.__f = __x;
>>>>> return (int)(__u.__u >> 31);
>>>>> }
>>>>>
>>>>
>>>>I don't think anyone will disagree that unions are /sometimes/ used for
>>>>type-punning in C.
>>>>
>>>>But when you claim that this is the /only/ use, outside tiny embedded
>>>>systems, you are talking drivel.
>>>
>>> So other than the VERY occasional uses of saving memory or reducing the
>>amount
>>> pushed onto a stack in a function call/return, what would you say is the main
>>
>>> use for a union then?
>>
>>In C++11 you can use objects in union....
>
> Possibly not a good idea if a virtual function table is anywhere in that
> object. Otherwise it would be no different to a C struct.
Why?
>
>>> Many C header files and source code will be included into a C++ project. In
>>> any sane world C++ *will* support the same union rules as C because it has
>>> to regardless of whatever the standards committee in their ivory tower say.
>>
>>Depends on compiler...
>
> Name one compiler that doesn't.
All that headers usually have #ifdef __cplusplus ...
>
--
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-01 09:07 +0000 |
| Message-ID | <quhnh5$1ck0$1@gioia.aioe.org> |
| In reply to | #70877 |
On Tue, 31 Dec 2019 16:42:30 GMT Melzzzzz <Melzzzzz@zzzzz.com> wrote: >On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote: >> On Tue, 31 Dec 2019 12:00:33 GMT >> Possibly not a good idea if a virtual function table is anywhere in that >> object. Otherwise it would be no different to a C struct. > >Why? Is this a trick question? Because where the VFT is placed is compiler dependant and it will make a difference on what line up wheres in the union with the other types. >>>Depends on compiler... >> >> Name one compiler that doesn't. > >All that headers usually have #ifdef __cplusplus ... Name one compiler that doesn't.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-01 15:48 +0200 |
| Message-ID | <qui7uu$nmo$1@dont-email.me> |
| In reply to | #70919 |
On 1.01.2020 11:07, boltar@nowhere.org wrote: > On Tue, 31 Dec 2019 16:42:30 GMT > Melzzzzz <Melzzzzz@zzzzz.com> wrote: >> On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote: >>> On Tue, 31 Dec 2019 12:00:33 GMT >>> Possibly not a good idea if a virtual function table is anywhere in that >>> object. Otherwise it would be no different to a C struct. >> >> Why? > > Is this a trick question? Because where the VFT is placed is compiler dependant > and it will make a difference on what line up wheres in the union with the > other types. No shit, Sherlock! Are we now finally getting somewhere? Of course, if there might be an unknown number of vtable pointers and stuff in the beginning of the object, its fields might not line up with other union members and one cannot cast it (e.g. via union type punning) to other union type willy-nilly. That's EXACTLY what everybody has tried to explain you for several days already: one is allowed to access ONLY the ACTIVE member of the union at any time moment. Good that you are starting to understand it now.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-02 09:24 +0000 |
| Message-ID | <qukcs3$1hug$1@gioia.aioe.org> |
| In reply to | #70927 |
On Wed, 01 Jan 2020 15:48:12 +0200 Paavo Helde <myfirstname@osa.pri.ee> wrote: >On 1.01.2020 11:07, boltar@nowhere.org wrote: >> On Tue, 31 Dec 2019 16:42:30 GMT >> Melzzzzz <Melzzzzz@zzzzz.com> wrote: >>> On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote: >>>> On Tue, 31 Dec 2019 12:00:33 GMT >>>> Possibly not a good idea if a virtual function table is anywhere in that >>>> object. Otherwise it would be no different to a C struct. >>> >>> Why? >> >> Is this a trick question? Because where the VFT is placed is compiler >dependant >> and it will make a difference on what line up wheres in the union with the >> other types. > >No shit, Sherlock! Are we now finally getting somewhere? Of course, if >there might be an unknown number of vtable pointers and stuff in the >beginning of the object, its fields might not line up with other union >members and one cannot cast it (e.g. via union type punning) to other >union type willy-nilly. > >That's EXACTLY what everybody has tried to explain you for several days Really? Please state exactly where I ever suggested using unions for classes rather than just POD. >already: one is allowed to access ONLY the ACTIVE member of the union at >any time moment. A variant IS NOT a union, its simply a multi type single value container. The point of a union is to access MORE than 1 type without doing any sets in between. >Good that you are starting to understand it now. Perhaps you need to improve your English. You understand the words and grammar but you clearly don't always understand the intent. Don't worry , I have the same problem when speaking French - just understanding whats being said literally doesn't always help, n'est pas?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-02 12:02 +0200 |
| Message-ID | <qukf49$tar$1@dont-email.me> |
| In reply to | #70951 |
On 2.01.2020 11:24, boltar@nowhere.org wrote: > On Wed, 01 Jan 2020 15:48:12 +0200 > Paavo Helde <myfirstname@osa.pri.ee> wrote: >> On 1.01.2020 11:07, boltar@nowhere.org wrote: >>> On Tue, 31 Dec 2019 16:42:30 GMT >>> Melzzzzz <Melzzzzz@zzzzz.com> wrote: >>>> On 2019-12-31, boltar@nowhere.org <boltar@nowhere.org> wrote: >>>>> On Tue, 31 Dec 2019 12:00:33 GMT >>>>> Possibly not a good idea if a virtual function table is anywhere in that >>>>> object. Otherwise it would be no different to a C struct. >>>> >>>> Why? >>> >>> Is this a trick question? Because where the VFT is placed is compiler >> dependant >>> and it will make a difference on what line up wheres in the union with the >>> other types. >> >> No shit, Sherlock! Are we now finally getting somewhere? Of course, if >> there might be an unknown number of vtable pointers and stuff in the >> beginning of the object, its fields might not line up with other union >> members and one cannot cast it (e.g. via union type punning) to other >> union type willy-nilly. >> >> That's EXACTLY what everybody has tried to explain you for several days > > 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 only exception is about standard-layout structs that share a common initial sequence, which does not involve the type punning you are advocating. > >> already: one is allowed to access ONLY the ACTIVE member of the union at >> any time moment. > > A variant IS NOT a union, its simply a multi type single value container. The > 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. > >> Good that you are starting to understand it now. > > Perhaps you need to improve your English. And you need to improve your sarcasm detectors!
[toc] | [prev] | [next] | [standalone]
Page 7 of 16 — ← Prev page 1 … 5 6 [7] 8 9 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web