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 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 18:51 +0100 |
| Message-ID | <qug1r7$e49$1@dont-email.me> |
| In reply to | #70893 |
On 31/12/2019 18:35, Bonita Montero wrote: >>> That's your personal taste and not C++. > >> What part of "the compiler and flags that I use" made you think it was >> something other than my personal choice? > > Those which make every warning an error; that's very uncommon > and nerdish. I simply don't think you have experience with quality programming. Some people write code where bugs are not acceptable. There are many things required in a development process to achieve a zero bugs (or at least, as low a chance of bugs as achievable in the time and resource budget). Heavy use of compiler warnings, and a zero-warning build policy, is a simple, cheap and commonly used part of that. (Not all code is developed to such standards, of course - otherwise software would be ridiculously expensive in many cases.) > >>> That doesn't matter if because all compilers support this trivial >>> kind of aliasing. > >> Yes, it matters - it matters to people that want to write correct >> code, and not "I know this is crap, but it worked when I tried it" code. > > The code I have shown works with any compiler. > A "C++ implementation" covers the compiler, library and choice of flags and options. Sure, the compiler I use could be made to accept the code you wrote - but not with the flags I require. >> What you wrote is not particularly common, I think. > > You think that yout habits are the center of the world. > No, I think they are /my/ habits. Some of them are common, some are uncommon. Some are common in the branch I work in but uncommon in more general programming. (I find comparisons between different types of programming arenas to be an interesting topic in these newsgroups.) I don't think casts like yours are common in any area of programming. I could be wrong here, of course, but that is what I think. If people whose opinion I respect tell me otherwise, I may change that opinion - but it is usually extremely difficult to get an idea of what techniques are common or rare in C++ programming "in general". > >>>> The aliasing abuse here is not compiler specific - it is in the >>>> standards. ... > >>> The standards don't count in this specific case. > >> Right... > >> That's because compilers implement C++ based on "Bonita says so" >> rules rather than the standards. I'll bear that in mind. > > No, what I wrot is simply common because it is very convenient > over having a union. Look, the common way of writing the code in question is not to faff around with casts /or/ unions - you write "if (x < 0)". And people who are concerned with accurate IEEE floating point, and careful handling of NaNs and the rest of it, will write "if (signbit(x))". Almost the only people who care about the representation details of the floating point types are the ones /implementing/ such functions or macros - and they can rely on whatever compiler-specific features they want.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 18:59 +0100 |
| Message-ID | <qug29d$66a$1@news.albasani.net> |
| In reply to | #70895 |
> I simply don't think you have experience with quality programming. Your quality-programming is not a matter of maintainability or if the code is de-facto guaranteed to work but partitially an aesthetic baublery. > Some people write code where bugs are not acceptable. What I showed works with any compiler.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2019-12-31 12:23 -0800 |
| Message-ID | <c4807b4e-241a-432e-a675-20932280e105@googlegroups.com> |
| In reply to | #70893 |
On Tuesday, 31 December 2019 19:36:08 UTC+2, Bonita Montero wrote: > >> That's your personal taste and not C++. > > > What part of "the compiler and flags that I use" made you think it was > > something other than my personal choice? > > Those which make every warning an error; that's very uncommon > and nerdish. People with infantile reactions how rules of project they join are so very "uncommon" and "nerdish" are soon back on streets searching for project with more "common" and "dumboish" rules.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-31 16:14 -0800 |
| Message-ID | <qugo93$12ng$1@gioia.aioe.org> |
| In reply to | #70879 |
On 12/31/2019 8:51 AM, David Brown wrote: > On 31/12/2019 15:45, Bonita Montero wrote: >>>>> This is not guaranteed. >> >>>> This de-facto guaranteed. >> >>> "de-facto" means it is /not/ guaranteed ! >> >> de-facto means practically, but not theoretically. >> > > Yes - and therefore /not/ guaranteed by the standards or any other > actual /written/ information. > > Not that any of this applies to your code, anyway. You've written an > expression that worked the way you expected in your tests. That's fine > if you are writing code for one specific compiler with one specific set > of flags, and you test appropriately - sometimes that is what you want > in code. (This is not uncommon in my line of work - but I then claim > "it works in this case, in these precise build circumstances" - not > "it's de-facto", or "it's guaranteed to work".) > > >>>> This absolutely hasn't anything to do with the aliasing-options >>>> of the compiler; at least with the code I showed. >> >>> The code you showed would not compile with the compiler and flags that I >>> use. >> >> It will. > > Why on earth would you deny that? > >> >>> It is not a matter of it might generate unexpected code - it is a matter >>> of failing to compile. >>> And the flags I use here are not particularly unusual amongst people who >>> care about code quality: >>> gcc -O2 -Wall -Werror >>> Guess what the fatal error message is? >> >> Treating warnings as errors is not what the C++-standard mandates; >> that's compiler-specific. > > What part of "the compiler and flags that I use" made you think I was > referring to the standards? > > The C++ (and C) standards make it clear that the accessing via the cast > you had was undefined behaviour. A compiler is free to treat that as it > wants - including halting compilation with an error, and also including > generating code as though the access were allowed, and also including > generating the result the programmer wanted while testing and quietly > corrupting data once the program is deployed. > >> And no one uses -Wall practically because >> it generates a lot of nonsense-warnings and most libraries will not >> compile without a imense number of warnings. >> > > Nonsense. No one uses "/Wall" (if that is the right option) on MSVC > because it really means "enable all warnings supported by the compiler" > and generates a great deal of noise for most code. What if one likes looking at all the warnings, and creates a little game called, no warnings, altered code... joking around here. ;^) Most gcc and clang > users who see their compiler as a development tool and not just a dumb > translator, use -Wall regularly - because there it means "enable a set > of warnings appropriate for almost all good code". > >>>> No, that's a different issue because of the lack of the opportunity >>>> to detect the aliasing. >> >>> Again, you are wrong. >> >> No, any compiler will detect the aliasing independent of any aliasing >> -specific compiler-optionns. > > The aliasing abuse here is not compiler specific - it is in the > standards. /Detection/ of the abuse, and how the code is otherwise > treated, is compiler-specific because the standards give no instructions > on how it is to be handled.
[toc] | [prev] | [next] | [standalone]
| From | "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> |
|---|---|
| Date | 2019-12-31 16:52 -0800 |
| Message-ID | <qugqgl$1cec$1@gioia.aioe.org> |
| In reply to | #70912 |
On 12/31/2019 4:14 PM, Chris M. Thomasson wrote: > On 12/31/2019 8:51 AM, David Brown wrote: >> On 31/12/2019 15:45, Bonita Montero wrote: [...] > What if one likes looking at all the warnings, and creates a little game > called, no warnings, altered code... joking around here. ;^) Well, actually, not joking. [...]
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-31 18:58 +0200 |
| Message-ID | <qufuok$r5m$1@dont-email.me> |
| In reply to | #70870 |
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). > 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 18:00 +0100 |
| Message-ID | <qufurq$f65$2@news.albasani.net> |
| In reply to | #70881 |
>> 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). -Wall includes useful als well as rather useless child-proof locks.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-31 19:21 +0200 |
| Message-ID | <qug027$3dt$1@dont-email.me> |
| In reply to | #70883 |
On 31.12.2019 19:00, 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). > > -Wall includes useful als well as rather useless child-proof locks. If it did so in gcc we could not use it in our production builds. And anyway, the "dereferencing type-punned pointer will break strict-aliasing rules" is not a useless child-proofing warning, it declares that the compiler is about to emit code which might not work at all as intended. I have been personally bitten about that in the past.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2019-12-31 18:22 +0100 |
| Message-ID | <qug053$3e2$2@dont-email.me> |
| In reply to | #70883 |
On 31/12/2019 18:00, 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). > > -Wall includes useful als well as rather useless child-proof locks. Would you like to give some examples? (I realise this will require you to actually look something up, instead of making up your arguments as you go along.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 18:46 +0100 |
| Message-ID | <qug1hg$7ch$1@news.albasani.net> |
| In reply to | #70891 |
> Would you like to give some examples? (I realise this will require you > to actually look something up, instead of making up your arguments as > you go along.) There are not much, but these are useless: -Wcomment It's not rare that you first comment out a part with // and then the outer block with /* */. This isn't really a problem. -Wenum-compare Unscoped enums are in the same namespace so they should be all comparable. -Wmissing-braces That's really a useless aesthetic warning. -Wreorder It's very rare that the order of initialization-calls counts. -Wunused-function This would be disturbing if you would have the function in the code for a later purpose. But I agree that the vast majority of -Wall-warnings makes sense.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2019-12-31 20:30 +0200 |
| Message-ID | <qug44u$rs6$1@dont-email.me> |
| In reply to | #70894 |
On 31.12.2019 19:46, Bonita Montero wrote: >> Would you like to give some examples? (I realise this will require >> you to actually look something up, instead of making up your arguments >> as you go along.) > > There are not much, but these are useless: > > -Wcomment > It's not rare that you first comment out a part with // and > then the outer block with /* */. This isn't really a problem. Your description does not match what this warning is doing. It warns about /* inside /*. Usually it is easy to fix, replace inner /* with //. > -Wenum-compare > Unscoped enums are in the same namespace so they should be > all comparable. I think this is a really useful comment. If I have mixed up my enums I would want to know that. > -Wmissing-braces > That's really a useless aesthetic warning. Never seen that warning. Probably because I take care to write my initializers. > -Wreorder > It's very rare that the order of initialization-calls counts. This is the only one which I agree with. It should not warn if the initializer is a constant expression, at least. > -Wunused-function > This would be disturbing if you would have the function in the > code for a later purpose. So you are checking in untested code. > > But I agree that the vast majority of -Wall-warnings makes sense. ok
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2019-12-31 19:44 +0100 |
| Message-ID | <qug4u4$tpk$1@news.albasani.net> |
| In reply to | #70900 |
>> -Wenum-compare >> Unscoped enums are in the same namespace so they should be >> all comparable. > I think this is a really useful comment. If I have mixed up my enums I > would want to know that. That's a child-proof lock. >> -Wmissing-braces >> That's really a useless aesthetic warning. > Never seen that warning. Probably because I take care to write my > initializers. It's rare but useless. >> -Wunused-function >> This would be disturbing if you would have the function in the >> code for a later purpose. > So you are checking in untested code. I'll check it later and that's quite ok.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-10 08:10 -0800 |
| Message-ID | <86wo9z47i9.fsf@linuxsc.com> |
| In reply to | #70900 |
Paavo Helde <myfirstname@osa.pri.ee> writes: > On 31.12.2019 19:46, Bonita Montero wrote: [...] >> -Wunused-function >> This would be disturbing if you would have the function in the >> code for a later purpose. > > So you are checking in untested code. On the contrary, such unused functions are completely tested: any function that is never called cannot possibly misbehave. The warning message saying the function is unused is the success indicator for testing the function in question. It is only functions that are called that might contain program errors.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-11 13:03 +0100 |
| Message-ID | <qvcdie$pbk$1@dont-email.me> |
| In reply to | #71260 |
On 10/01/2020 17:10, Tim Rentsch wrote: > Paavo Helde <myfirstname@osa.pri.ee> writes: > >> On 31.12.2019 19:46, Bonita Montero wrote: > > [...] > >>> -Wunused-function >>> This would be disturbing if you would have the function in the >>> code for a later purpose. >> >> So you are checking in untested code. > > On the contrary, such unused functions are completely tested: > any function that is never called cannot possibly misbehave. The > warning message saying the function is unused is the success > indicator for testing the function in question. It is only > functions that are called that might contain program errors. > The people who maintain your code must really love you! If you have written code that is not used anywhere, then presumably it was either used in the past, or it is expected that it might be used in the future. If it could be used in the future, then it should either be tested, or it should somehow be marked that it is not tested. And if it is not going to be used in the future, remove it. (Of course there will often be stages in development where it is fine to check in untested code.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-12 07:50 +1300 |
| Message-ID | <h7ujnnFsqhkU4@mid.individual.net> |
| In reply to | #71284 |
On 12/01/2020 01:03, David Brown wrote: > On 10/01/2020 17:10, Tim Rentsch wrote: >> Paavo Helde <myfirstname@osa.pri.ee> writes: >> >>> On 31.12.2019 19:46, Bonita Montero wrote: >> >> [...] >> >>>> -Wunused-function >>>> This would be disturbing if you would have the function in the >>>> code for a later purpose. >>> >>> So you are checking in untested code. >> >> On the contrary, such unused functions are completely tested: >> any function that is never called cannot possibly misbehave. The >> warning message saying the function is unused is the success >> indicator for testing the function in question. It is only >> functions that are called that might contain program errors. >> > > The people who maintain your code must really love you! > > If you have written code that is not used anywhere, then presumably it > was either used in the past, or it is expected that it might be used in > the future. If it could be used in the future, then it should either be > tested, or it should somehow be marked that it is not tested. And if it > is not going to be used in the future, remove it. > > (Of course there will often be stages in development where it is fine to > check in untested code.) Are there? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-11 11:55 -0800 |
| Message-ID | <058de297-201e-4251-92e1-b86f86608cdb@googlegroups.com> |
| In reply to | #71293 |
On Saturday, 11 January 2020 20:50:44 UTC+2, Ian Collins wrote: > On 12/01/2020 01:03, David Brown wrote: > > On 10/01/2020 17:10, Tim Rentsch wrote: > >> Paavo Helde <myfirstname@osa.pri.ee> writes: > >> > >>> On 31.12.2019 19:46, Bonita Montero wrote: > >> > >> [...] > >> > >>>> -Wunused-function > >>>> This would be disturbing if you would have the function in the > >>>> code for a later purpose. > >>> > >>> So you are checking in untested code. > >> > >> On the contrary, such unused functions are completely tested: > >> any function that is never called cannot possibly misbehave. The > >> warning message saying the function is unused is the success > >> indicator for testing the function in question. It is only > >> functions that are called that might contain program errors. > >> > > > > The people who maintain your code must really love you! > > > > If you have written code that is not used anywhere, then presumably it > > was either used in the past, or it is expected that it might be used in > > the future. If it could be used in the future, then it should either be > > tested, or it should somehow be marked that it is not tested. And if it > > is not going to be used in the future, remove it. > > > > (Of course there will often be stages in development where it is fine to > > check in untested code.) > > Are there? Depends what you mean by untested? Merging untested pull requests is kind of crime but untested (and even non-compiling) check in does not matter.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-11 23:59 +0100 |
| Message-ID | <qvdk14$7i4$1@dont-email.me> |
| In reply to | #71293 |
On 11/01/2020 19:50, Ian Collins wrote: > On 12/01/2020 01:03, David Brown wrote: >> (Of course there will often be stages in development where it is fine to >> check in untested code.) > > Are there? > Of course. Even if you are doing test-driven development, when you are very rigid (some might say "obsessed" or "fanatic") on everything being tested at the earliest possible moment, it is surely possible that you want to store things away in your version control system despite being only half-done. But if you are using other development methodologies, it is entirely reasonable to untested code checked in. You'd likely put it in a development or private branch rather than a master branch, but you'd still want it checked in if it represents significant effort or if it should be shared with others.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-01 23:04 +0100 |
| Message-ID | <quj51q$18j$1@dont-email.me> |
| In reply to | #70894 |
On 31/12/2019 18:46, Bonita Montero wrote: >> Would you like to give some examples? (I realise this will require >> you to actually look something up, instead of making up your arguments >> as you go along.) > > There are not much, but these are useless: Thanks for making this effort. > > -Wcomment > It's not rare that you first comment out a part with // and > then the outer block with /* */. This isn't really a problem. Yes, it is a problem - it is a symptom of disordered code with inconsistent styling and coding habits. Such code is harder to read - it is harder to spot mistakes, and harder to maintain correctly. > -Wenum-compare > Unscoped enums are in the same namespace so they should be > all comparable. In C, there is only one namespace, so it is useful to have this on - comparing values from different enumeration types is usually an error in the code. In C++, you are even less likely to want to compare values of different types, because you are usually aiming for stricter typing. In gcc, this is enabled by default in C++ - you get this warning even without -Wall. > -Wmissing-braces > That's really a useless aesthetic warning. If this is triggered, you either have a very lazy style of writing initialisers with a disregard for code clarity and maintainability, or a bug in the code. I believe a lot of people want a message in either case. > -Wreorder > It's very rare that the order of initialization-calls counts. I can't comment on how often it happens, but sometimes the order /does/ matter. It is a bad idea to have code written so that it appears to work in one order, when in fact it is executed in a different order. > -Wunused-function > This would be disturbing if you would have the function in the > code for a later purpose. > The various "unused" options can often trigger during early development, but you want them later. Unused code means untested code, which is a buried bomb waiting for trouble during later changes to the code. > But I agree that the vast majority of -Wall-warnings makes sense. And if you have a particular dislike for any of them, you can disable them. "-Wall" is a good starting point for a lot of code, but it is not perfect for all code, and does not cover many other useful warnings (some of which I think should enabled by default). I use a great many other gcc warnings in my code - many more than are in -Wall or -Wextra. But I am fully aware that many don't match the needs of a lot of other programmers. The aim of "-Wall" is that it should be useful to a substantial proportion of programmers and programs without warning about code that is intentionally written as it is. It's not perfect - but it is pretty good.
[toc] | [prev] | [next] | [standalone]
| From | Richard Damon <Richard@Damon-Family.org> |
|---|---|
| Date | 2020-01-04 20:04 -0500 |
| Message-ID | <0DaQF.26308$gQ2.14552@fx25.iad> |
| In reply to | #70894 |
On 12/31/19 12:46 PM, Bonita Montero wrote: >> Would you like to give some examples? (I realise this will require >> you to actually look something up, instead of making up your arguments >> as you go along.) > > There are not much, but these are useless: > > -Wcomment > It's not rare that you first comment out a part with // and > then the outer block with /* */. This isn't really a problem. But that doesn't generate a warning. -Wcomment warns on /* /* */ */ (nested /* comments) or // \ Using a line continuation slash inside a line based comment > -Wenum-compare > Unscoped enums are in the same namespace so they should be > all comparable. They may be legally comparable (so not an ERROR), but I can't think of many cases where I would want to compare an enum to values of a different enums. > -Wmissing-braces > That's really a useless aesthetic warning. Maybe, not hard to get it right. Bad aesthetics are a good way to hide problems. > -Wreorder > It's very rare that the order of initialization-calls counts. but sometime it does (if one member uses the value of another in its initalization). Keeping initialization matching order of definition avoids a number of surprises. It also isn't that hard to keep the order right (especially if you use this warning) > -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. > > But I agree that the vast majority of -Wall-warnings makes sense.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-05 13:36 +0100 |
| Message-ID | <qusl8j$ei9$1@news.albasani.net> |
| In reply to | #71124 |
>> -Wcomment >> It's not rare that you first comment out a part with // and >> then the outer block with /* */. This isn't really a problem. > But that doesn't generate a warning. -Wcomment warns on > /* /* */ */ (nested /* comments) As there are no nested "/* */", "/* /* */ */" will be interpreted as "/* /* */" + "*/". So after the first "/* /* */"-Block there will be errors because the comments before the second "*/"-block can't be compiled anyway. So what are this warnings good for if there are compiletime-errors anyway? >> -Wenum-compare >> Unscoped enums are in the same namespace so they should be >> all comparable. > They may be legally comparable (so not an ERROR), but I can't think > of many cases where I would want to compare an enum to values of a > different enums. F.e. you might have multiple extendible ranges of error-codes. In the first union you might have the base-offsets of several ranges and in different additional unions managed by other developers there might be the actual errorcodes within this ranges. >> -Wmissing-braces >> That's really a useless aesthetic warning. > Maybe, not hard to get it right. > Bad aesthetics are a good way to hide problems. Aesthetical "problems" are aesthetical but not real problems. >> -Wreorder >> It's very rare that the order of initialization-calls counts. > but sometime it does (if one member uses the value of another in its > initalization). Keeping initialization matching order of definition > avoids a number of surprises. It also isn't that hard to keep the order > right (especially if you use this warning) This is rarely useful. >> -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 prevent this useless compiler-warning?
[toc] | [prev] | [next] | [standalone]
Page 6 of 16 — ← Prev page 1 … 4 5 [6] 7 8 … 16 Next page →
Back to top | Article view | comp.lang.c++
csiph-web