Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #69548 > unrolled thread
| Started by | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| First post | 2019-11-04 20:48 +0100 |
| Last post | 2020-02-26 02:22 +0000 |
| Articles | 20 on this page of 219 — 25 participants |
Back to article view | Back to comp.lang.c++
two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 20:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-04 21:19 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 14:39 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:31 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 11:23 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 15:43 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 16:58 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-05 21:45 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 13:33 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 13:51 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 14:37 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 15:38 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 15:53 +0100
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-06 10:06 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-06 17:00 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 17:47 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 17:54 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-06 20:00 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:13 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:44 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 20:36 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 22:54 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-07 00:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 17:54 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 18:15 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 18:33 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 10:55 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 20:15 +0100
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 20:53 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:25 +0200
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-06 23:05 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-07 10:23 +0200
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 22:20 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-06 22:12 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:24 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 07:14 -0700
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 11:52 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-10 16:31 +0200
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 19:02 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 12:08 +0200
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-11 13:59 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2019-11-11 17:09 +0200
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2019-11-18 07:40 -0500
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:27 -0800
Re: two's complement idea cdalten@gmail.com - 2020-01-24 05:39 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 17:53 +0200
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:31 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 21:48 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 07:08 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 09:30 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-06 09:57 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 09:02 -0800
Re: two's complement idea scott@slp53.sl.home (Scott Lurndal) - 2019-11-05 17:15 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 10:19 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-05 19:31 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 11:55 -0800
Re: two's complement idea Manfred <noname@add.invalid> - 2019-11-05 22:48 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-05 15:49 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 06:13 -0800
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 23:00 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-06 05:26 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-06 21:50 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 02:01 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-08 14:03 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-08 12:08 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 13:17 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-10 14:37 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 17:08 +0100
Re: two's complement idea Manfred <noname@invalid.add> - 2019-11-10 18:34 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-11 07:48 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-10 21:31 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-04 23:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-05 10:32 +0100
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-04 19:55 -0700
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-05 05:52 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2019-11-05 18:17 +1300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-09 05:55 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2019-11-09 06:33 -0700
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 07:46 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-09 06:46 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-11-28 12:19 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2019-11-29 00:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 09:15 +0100
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2019-11-29 10:58 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2019-11-29 12:49 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2019-12-07 07:53 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-12-07 08:22 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-10 20:44 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-10 23:44 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-14 07:08 -0800
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-14 08:42 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-21 02:09 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-21 05:14 -0800
Re: two's complement idea Daniel <danielaparker@gmail.com> - 2020-01-21 13:08 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-22 00:07 -0500
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-21 23:21 -0800
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 01:51 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-22 11:28 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 11:52 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-22 04:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:19 -0700
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-04-02 08:07 -0700
Re: two's complement idea boltar@nowhere.org - 2020-01-21 16:44 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-21 20:01 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-22 11:26 +0000
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2020-01-22 20:04 +0100
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-22 11:30 -0800
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 19:57 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:24 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-24 07:29 +1300
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-23 10:03 +1300
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-23 10:09 +0100
Re: two's complement idea boltar@nowhere.org - 2020-01-23 09:29 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:08 +0000
Re: two's complement idea boltar@nowhere.org - 2020-01-24 12:27 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 01:06 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 10:07 +0100
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 11:36 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-24 17:34 -0800
Re: two's complement idea Siri Cruise <chine.bleu@yahoo.com> - 2020-01-24 17:57 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 12:19 +0000
Re: two's complement idea Bo Persson <bo@bo-persson.se> - 2020-01-24 14:19 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 14:11 +0000
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 17:26 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-24 17:35 +0000
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-24 22:27 +0200
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:21 -0500
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 11:06 +1300
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-24 22:12 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-24 23:24 -0500
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 09:04 +0000
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 04:15 -0800
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 19:55 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 00:05 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 01:19 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-25 19:50 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 11:57 +0000
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-25 13:42 +0000
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 14:58 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:58 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:34 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-25 12:41 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 16:08 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 02:20 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-27 15:03 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 06:44 -0800
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-03-06 10:18 +0200
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-02 07:05 -0700
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-04-02 20:03 +0300
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-04-04 12:37 -0700
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 07:45 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 19:56 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 09:49 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 21:33 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:00 +1300
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-25 22:23 +0000
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-26 11:46 +1300
Re: two's complement idea Paavo Helde <myfirstname@osa.pri.ee> - 2020-01-26 10:55 +0200
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2020-01-26 03:47 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:28 -0800
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-25 22:22 +0000
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-01-25 18:24 -0500
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 12:54 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 12:44 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 14:58 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 14:53 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 19:10 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:20 -0600
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-26 20:51 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 21:02 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-26 19:06 -0800
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 18:50 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 14:18 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-27 22:13 +0100
Re: two's complement idea Bart <bc@freeuk.com> - 2020-01-27 21:38 +0000
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 19:37 -0600
Re: two's complement idea Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-01-27 19:15 -0800
Re: two's complement idea "Fred. Zwarts" <F.Zwarts@KVI.nl> - 2020-01-28 11:45 +0100
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 16:31 +1300
Re: two's complement idea Manfred <noname@add.invalid> - 2020-01-26 18:50 +0100
Re: two's complement idea Jorgen Grahn <grahn+nntp@snipabacken.se> - 2020-01-26 18:57 +0000
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 20:46 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-26 13:14 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-26 22:15 +0100
Re: two's complement idea Robert Wessel <robertwessel2@yahoo.com> - 2020-01-27 21:06 -0600
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-28 13:08 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:50 -0800
Re: two's complement idea Ian Collins <ian-news@hotmail.com> - 2020-01-27 08:21 +1300
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:14 +0100
Re: two's complement idea David Brown <david.brown@hesbynett.no> - 2020-01-25 20:12 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 07:48 -0800
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-02-18 18:46 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-09 17:03 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 06:56 +0100
Re: two's complement idea Christian Gollwitzer <auriocus@gmx.de> - 2019-11-05 08:24 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2019-11-05 08:35 +0100
Re: two's complement idea Öö Tiib <ootiib@hot.ee> - 2019-11-04 23:36 -0800
Re: two's complement idea James Kuyper <jameskuyper@alumni.caltech.edu> - 2019-11-05 09:19 -0500
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 08:32 +0100
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-22 09:23 +0100
Re: two's complement idea Bonita Montero <Bonita.Montero@gmail.com> - 2020-01-22 14:20 +0100
Re: two's complement idea Chris Vine <chris@cvine--nospam--.freeserve.co.uk> - 2020-01-22 13:37 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-01-27 01:17 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-01-27 12:35 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-15 05:56 -0800
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-16 09:17 +0100
Re: two's complement idea Richard Damon <Richard@Damon-Family.org> - 2020-02-21 19:35 -0500
Re: two's complement idea "Alf P. Steinbach" <alf.p.steinbach+usenet@gmail.com> - 2020-02-22 07:01 +0100
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-24 08:22 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-24 03:12 +0000
Re: two's complement idea cdalten@gmail.com - 2020-02-24 05:53 -0800
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 07:56 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-25 22:00 +0000
Re: two's complement idea Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-02-25 16:14 -0800
Re: two's complement idea cdalten@gmail.com - 2020-02-25 18:18 -0800
Re: two's complement idea cross@spitfire.i.gajendra.net (Dan Cross) - 2020-02-26 02:22 +0000
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-01-22 11:52 +0100 |
| Message-ID | <r099h0$rid$1@news.albasani.net> |
| In reply to | #71505 |
>> You mean nothing other than >> #undef min >> #undef max >> ? >> > That would work, unless there is something in the code that uses these > macros. (Presumably there is some reason for them being in windows.h in > the first place, and some code uses them.) > > But it must surely be possible to include "windows.h", then any other > windows-specific headers (that might rely on the windows.h definition of > the macros), then do the undef's, then include standard C++ headers, > application headers, and the main code. It might be a bit ugly - > personally I dislike anything that forces a particular ordering on > include files - but I can't think off hand of any reason it wouldn't work. If you include <Windows.h> and don't want min / max to be defined you have to #define NOMINMAX before including <Windows.h>.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-22 04:47 -0800 |
| Message-ID | <b0f47584-1b5c-44f7-8898-3bfe1dddc230@googlegroups.com> |
| In reply to | #71505 |
On Wednesday, 22 January 2020 12:28:11 UTC+2, David Brown wrote: > On 22/01/2020 10:51, Keith Thompson wrote: > > Öö Tiib <ootiib@hot.ee> writes: > > [...] > >> Macros like "min()" and "max()" from windows.h however screw up any > >> min and max. It does not matter if it is std::max(), std::numeric_limits<int>::max() or thatlib::suchstruct::max(). > >> Now and then someone trying to run some (perfectly well-formed > >> and portable) code on windows wastes some time with that > >> nuisance, globally, ... and there are nothing to do about it. > > > > You mean nothing other than > > #undef min > > #undef max > > ? > > > > That would work, unless there is something in the code that uses these > macros. (Presumably there is some reason for them being in windows.h in > the first place, and some code uses them.) > > But it must surely be possible to include "windows.h", then any other > windows-specific headers (that might rely on the windows.h definition of > the macros), then do the undef's, then include standard C++ headers, > application headers, and the main code. It might be a bit ugly - > personally I dislike anything that forces a particular ordering on > include files - but I can't think off hand of any reason it wouldn't work. Issue is manifesting as obscure compiler error messages in some standard library implementation file included by <limits> that most programmers who use C++ are not skilled enough to write themselves. Figuring out that it is because of #include <windows.h> in header (that they also likely did not write) takes some time, swapping the header files, adding #undefs or adding -D NOMINMAX to command line is trivial. Therefore macros can be used and are used in practice by major platform vendor to make things painful here, nuisance there and sucky at third place. Motivation of platform vendor is understandable, it wants to herd programmers to use C# on their platform. But why should it cause love towards macros to grow among C++ programmers?
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 07:19 -0700 |
| Message-ID | <86eet66kcj.fsf@linuxsc.com> |
| In reply to | #71485 |
James Kuyper <jameskuyper@alumni.caltech.edu> writes: > On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: > >> Tiib writes: >> >>> On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: >>> >>>> Tiib writes: >>>> >>>>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: >>>> >>>> [...] >>>> >>>>>> Your comments are not really about macros but about how various >>>>>> people misuse macros. Any language feature can be misused. >>>>>> My question is about macros, not about people who misuse them. >>>>> >>>>> Programmer who is ordered to write software for platform where he >>>>> can not avoid wasting workdays into dealing with that misuse of >>>>> feature by platform vendors still can not avoid disliking the >>>>> feature that allows such annoying misuses. Especially in places >>>>> where usage of inline functions, templates or constants would >>>>> be as simple but would not cause the issues existence of whose >>>>> you dismiss. >>>> >>>> That may be interesting but it doesn't address the question >>>> I was asking. >>> >>> Your question was "Why do C++ fans hate the C preprocessor so much?". >> >> Yes, and your responses don't speak to that question. They do >> explain why you don't like how some people use macros, but >> nothing about the macros themselves. My question is about >> reactions to the preprocessor (and macros in particular), not >> about reactions to how people might misuse it. Do you not >> understand the difference? > > Do you don't understand that he considers that the way they invite > misuse, might be precisely the thing that he finds objectionable about > macros? [...] Please understand this: Your understandings are not my understandings. Your motivations are not my motivations. Your goals are not my goals. Your assumptions about meaning and communication do not match my own. I have the impression that your question is meant to be rhetorical. Mine was not: it was asked as just a question, nothing more.
[toc] | [prev] | [next] | [standalone]
| From | James Kuyper <jameskuyper@alumni.caltech.edu> |
|---|---|
| Date | 2020-04-02 08:07 -0700 |
| Message-ID | <4d96f1dd-3d0e-493f-85d3-2229b28ebd63@googlegroups.com> |
| In reply to | #72753 |
On Thursday, April 2, 2020 at 10:19:50 AM UTC-4, Tim Rentsch wrote: > James Kuyper <jameskuyper@alumni.caltech.edu> writes: > > > On Tuesday, January 21, 2020 at 5:09:42 AM UTC-5, Tim Rentsch wrote: ... > >> Yes, and your responses don't speak to that question. They do > >> explain why you don't like how some people use macros, but > >> nothing about the macros themselves. My question is about > >> reactions to the preprocessor (and macros in particular), not > >> about reactions to how people might misuse it. Do you not > >> understand the difference? > > > > Do you don't understand that he considers that the way they invite > > misuse, might be precisely the thing that he finds objectionable about > > macros? [...] > > Please understand this: Your understandings are not my understandings. That is quite clear. You appear to misunderstand a great many things. > Your motivations are not my motivations. Certainly not - I'd be appalled to have motivations that would lead me to behave the way that you do! > I have the impression that your question is meant to be rhetorical. Not quite. Your rejection of his response as an answer to your question would make more sense if you had been unaware of the point I was raising, and I'm sincerely interested in knowing whether that was the case. I'd also be interested in knowing whether you might have rejected it as invalid or irrelevant, and if so, why. In a sense, it was a rhetorical question - I would have hoped for a meaningful response, but I was not surprised by your failure to give one. > Mine was not: it was asked as just a question, nothing more. Yes, but you claimed incorrectly that he had not answered your question, implying that you failed to understand how his response qualifies as an answer to your question. I was merely explaining that to you (without, to be fair, any expectation that you would understand my explanation).
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-21 16:44 +0000 |
| Message-ID | <r079pt$1ij1$1@gioia.aioe.org> |
| In reply to | #71481 |
On Tue, 21 Jan 2020 02:09:32 -0800 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >Tiib writes: > >> On Tuesday, 14 January 2020 17:08:45 UTC+2, Tim Rentsch wrote: >> >>> Tiib writes: >>> >>>> On Saturday, 11 January 2020 06:44:28 UTC+2, Tim Rentsch wrote: >>> >>> [...] >>> >>>>> Your comments are not really about macros but about how various >>>>> people misuse macros. Any language feature can be misused. >>>>> My question is about macros, not about people who misuse them. >>>> >>>> Programmer who is ordered to write software for platform where he >>>> can not avoid wasting workdays into dealing with that misuse of >>>> feature by platform vendors still can not avoid disliking the >>>> feature that allows such annoying misuses. Especially in places >>>> where usage of inline functions, templates or constants would >>>> be as simple but would not cause the issues existence of whose >>>> you dismiss. >>> >>> That may be interesting but it doesn't address the question >>> I was asking. >> >> Your question was "Why do C++ fans hate the C preprocessor so much?". > >Yes, and your responses don't speak to that question. They do >explain why you don't like how some people use macros, but >nothing about the macros themselves. My question is about >reactions to the preprocessor (and macros in particular), not >about reactions to how people might misuse it. Do you not >understand the difference? The sort of developers who hate macros are the ones who've never had to do cross platform development.
[toc] | [prev] | [next] | [standalone]
| From | Jorgen Grahn <grahn+nntp@snipabacken.se> |
|---|---|
| Date | 2020-01-21 20:01 +0000 |
| Message-ID | <slrnr2em4s.km3.grahn+nntp@frailea.sa.invalid> |
| In reply to | #71491 |
On Tue, 2020-01-21, boltar@nowhere.org wrote: ... > The sort of developers who hate macros are the ones who've never had to do > cross platform development. How about those of us who had to do it, and hated it? By the way, even for that scenario, the preprocessor is overused. See the "#ifdefs considered harmful" paper. /Jorgen PS. I don't hate macros. -- // Jorgen Grahn <grahn@ Oo o. . . \X/ snipabacken.se> O o .
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-22 11:26 +0000 |
| Message-ID | <r09bhj$1cbg$1@gioia.aioe.org> |
| In reply to | #71494 |
On 21 Jan 2020 20:01:32 GMT Jorgen Grahn <grahn+nntp@snipabacken.se> wrote: >On Tue, 2020-01-21, boltar@nowhere.org wrote: >.... >> The sort of developers who hate macros are the ones who've never had to do >> cross platform development. > >How about those of us who had to do it, and hated it? > >By the way, even for that scenario, the preprocessor is overused. How? If an API call isn't supported on a given platform you have no choice but to ifdef. >See the "#ifdefs considered harmful" paper. I have paint to watch drying instead. No doubt it comes from the same ivory tower that claims gotos should never be used.
[toc] | [prev] | [next] | [standalone]
| From | Christian Gollwitzer <auriocus@gmx.de> |
|---|---|
| Date | 2020-01-22 20:04 +0100 |
| Message-ID | <r0a6k9$569$1@dont-email.me> |
| In reply to | #71507 |
Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: > I have paint to watch drying instead. Nice idiom > No doubt it comes from the same ivory > tower that claims gotos should never be used. > Ivory tower, for sure? We have while, for, break, continue, return, and exceptions. All these compile to some sort of goto in machine code. What good reasons are left for a literal goto? I can see it in C for error handling (because it lacks exceptions) - in C++ there is hardly a good reason IMHO. Christian
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-01-22 11:30 -0800 |
| Message-ID | <87r1zr70gm.fsf@nosuchdomain.example.com> |
| In reply to | #71519 |
Christian Gollwitzer <auriocus@gmx.de> writes:
[...]
> What good reasons are left for a literal goto? I can see it in C for
> error handling (because it lacks exceptions) - in C++ there is hardly
> a good reason IMHO.
https://softwareengineering.stackexchange.com/a/133523/33478
--
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
Working, but not speaking, for Philips Healthcare
void Void(void) { Void(); } /* The recursive call of the void */
[toc] | [prev] | [next] | [standalone]
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2020-01-22 19:57 +0000 |
| Message-ID | <20200122195749.5a81e70a52048598b4c1d605@cvine--nospam--.freeserve.co.uk> |
| In reply to | #71519 |
On Wed, 22 Jan 2020 20:04:58 +0100 Christian Gollwitzer <auriocus@gmx.de> wrote: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: > > I have paint to watch drying instead. > Nice idiom > > > No doubt it comes from the same ivory > > tower that claims gotos should never be used. > > > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. It is a better solution than exceptions for breaking out of a nested loop, usually.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-23 10:03 +1300 |
| Message-ID | <h8rrl4F25s3U2@mid.individual.net> |
| In reply to | #71522 |
On 23/01/2020 08:57, Chris Vine wrote: > On Wed, 22 Jan 2020 20:04:58 +0100 > Christian Gollwitzer <auriocus@gmx.de> wrote: >> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>> I have paint to watch drying instead. >> Nice idiom >> >>> No doubt it comes from the same ivory >>> tower that claims gotos should never be used. >>> >> >> Ivory tower, for sure? We have while, for, break, continue, return, and >> exceptions. All these compile to some sort of goto in machine code. >> >> What good reasons are left for a literal goto? I can see it in C for >> error handling (because it lacks exceptions) - in C++ there is hardly a >> good reason IMHO. > > It is a better solution than exceptions for breaking out of a nested > loop, usually. Extracting the loop is better still! -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-23 09:24 +0000 |
| Message-ID | <r0bop3$12pk$1@gioia.aioe.org> |
| In reply to | #71524 |
On Thu, 23 Jan 2020 10:03:32 +1300 Ian Collins <ian-news@hotmail.com> wrote: >On 23/01/2020 08:57, Chris Vine wrote: >> On Wed, 22 Jan 2020 20:04:58 +0100 >> Christian Gollwitzer <auriocus@gmx.de> wrote: >>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>> I have paint to watch drying instead. >>> Nice idiom >>> >>>> No doubt it comes from the same ivory >>>> tower that claims gotos should never be used. >>>> >>> >>> Ivory tower, for sure? We have while, for, break, continue, return, and >>> exceptions. All these compile to some sort of goto in machine code. >>> >>> What good reasons are left for a literal goto? I can see it in C for >>> error handling (because it lacks exceptions) - in C++ there is hardly a >>> good reason IMHO. >> >> It is a better solution than exceptions for breaking out of a nested >> loop, usually. > >Extracting the loop is better still! Good luck with that.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-24 07:29 +1300 |
| Message-ID | <h8u6vcF25s3U4@mid.individual.net> |
| In reply to | #71528 |
On 23/01/2020 22:24, boltar@nowhere.org wrote: > On Thu, 23 Jan 2020 10:03:32 +1300 > Ian Collins <ian-news@hotmail.com> wrote: >> On 23/01/2020 08:57, Chris Vine wrote: >>> On Wed, 22 Jan 2020 20:04:58 +0100 >>> Christian Gollwitzer <auriocus@gmx.de> wrote: >>>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>>> I have paint to watch drying instead. >>>> Nice idiom >>>> >>>>> No doubt it comes from the same ivory >>>>> tower that claims gotos should never be used. >>>>> >>>> >>>> Ivory tower, for sure? We have while, for, break, continue, return, and >>>> exceptions. All these compile to some sort of goto in machine code. >>>> >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is hardly a >>>> good reason IMHO. >>> >>> It is a better solution than exceptions for breaking out of a nested >>> loop, usually. >> >> Extracting the loop is better still! > > Good luck with that. Thank you.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-23 10:03 +1300 |
| Message-ID | <h8rrl2F25s3U1@mid.individual.net> |
| In reply to | #71519 |
On 23/01/2020 08:04, Christian Gollwitzer wrote: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >> I have paint to watch drying instead. > Nice idiom > >> No doubt it comes from the same ivory >> tower that claims gotos should never be used. >> > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. With the help of clang-tidy warnings, we have finally cleansed our decades old code base of goto :) -- Ian
[toc] | [prev] | [next] | [standalone]
| From | "Fred. Zwarts" <F.Zwarts@KVI.nl> |
|---|---|
| Date | 2020-01-23 10:09 +0100 |
| Message-ID | <r0bnrq$t9g$1@gioia.aioe.org> |
| In reply to | #71519 |
Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: > Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >> I have paint to watch drying instead. > Nice idiom > >> No doubt it comes from the same ivory >> tower that claims gotos should never be used. >> > > Ivory tower, for sure? We have while, for, break, continue, return, and > exceptions. All these compile to some sort of goto in machine code. > > What good reasons are left for a literal goto? I can see it in C for > error handling (because it lacks exceptions) - in C++ there is hardly a > good reason IMHO. > > Christian Maybe to exit nested loops? I wonder why C++ does not have named loops, so that in a break it would be possible to specify which loop to exit.
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-23 09:29 +0000 |
| Message-ID | <r0bp1g$148e$1@gioia.aioe.org> |
| In reply to | #71526 |
On Thu, 23 Jan 2020 10:09:15 +0100 "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>> I have paint to watch drying instead. >> Nice idiom >> >>> No doubt it comes from the same ivory >>> tower that claims gotos should never be used. >>> >> >> Ivory tower, for sure? We have while, for, break, continue, return, and >> exceptions. All these compile to some sort of goto in machine code. >> >> What good reasons are left for a literal goto? I can see it in C for >> error handling (because it lacks exceptions) - in C++ there is hardly a >> good reason IMHO. >> >> Christian > >Maybe to exit nested loops? I wonder why C++ does not have named loops, >so that in a break it would be possible to specify which loop to exit. That would be a much more useful addition to the language than the endless edge case rubbish (lambda capture initialisation, digit seperators, auto returns) and pointless STL classes and defs (optional, variant, byte, any, data()) that they've thrown in since 2011.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 01:08 +0000 |
| Message-ID | <KsrWF.100713$UPz1.20603@fx15.am4> |
| In reply to | #71529 |
On 23/01/2020 09:29, boltar@nowhere.org wrote: > On Thu, 23 Jan 2020 10:09:15 +0100 > "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >> Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>> I have paint to watch drying instead. >>> Nice idiom >>> >>>> No doubt it comes from the same ivory >>>> tower that claims gotos should never be used. >>>> >>> >>> Ivory tower, for sure? We have while, for, break, continue, return, and >>> exceptions. All these compile to some sort of goto in machine code. >>> >>> What good reasons are left for a literal goto? I can see it in C for >>> error handling (because it lacks exceptions) - in C++ there is hardly a >>> good reason IMHO. >>> >>> Â Â Â Â Christian >> >> Maybe to exit nested loops? I wonder why C++ does not have named loops, >> so that in a break it would be possible to specify which loop to exit. > > That would be a much more useful addition to the language than the endless edge > case rubbish (lambda capture initialisation, digit seperators, auto returns) > and pointless STL classes and defs (optional, variant, byte, any, data()) > that they've thrown in since 2011. > Digit separators are genuinely useful (and also incredibly simple to implement, compared to the rest of that lot). What's the problem with them?
[toc] | [prev] | [next] | [standalone]
| From | boltar@nowhere.org |
|---|---|
| Date | 2020-01-24 12:27 +0000 |
| Message-ID | <r0enql$1krl$1@gioia.aioe.org> |
| In reply to | #71534 |
On Fri, 24 Jan 2020 01:08:54 +0000 Bart <bc@freeuk.com> wrote: >On 23/01/2020 09:29, boltar@nowhere.org wrote: >> On Thu, 23 Jan 2020 10:09:15 +0100 >> "Fred. Zwarts" <F.Zwarts@KVI.nl> wrote: >>> Op 22.jan..2020 om 20:04 schreef Christian Gollwitzer: >>>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org: >>>>> I have paint to watch drying instead. >>>> Nice idiom >>>> >>>>> No doubt it comes from the same ivory >>>>> tower that claims gotos should never be used. >>>>> >>>> >>>> Ivory tower, for sure? We have while, for, break, continue, return, and >>>> exceptions. All these compile to some sort of goto in machine code. >>>> >>>> What good reasons are left for a literal goto? I can see it in C for >>>> error handling (because it lacks exceptions) - in C++ there is hardly a >>>> good reason IMHO. >>>> >>>> Â Â Â Â Christian >>> >>> Maybe to exit nested loops? I wonder why C++ does not have named loops, >>> so that in a break it would be possible to specify which loop to exit. >> >> That would be a much more useful addition to the language than the endless >edge >> case rubbish (lambda capture initialisation, digit seperators, auto returns) >> and pointless STL classes and defs (optional, variant, byte, any, data()) >> that they've thrown in since 2011. >> > >Digit separators are genuinely useful (and also incredibly simple to >implement, compared to the rest of that lot). What's the problem with them? Well ok, I'm sure they can make the code a little bit more readable. But in the scheme of things that it would be nice to have in C++ they were hardly top of the list whereas named loops is an extremely useful language construct and should be easy to implement.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-24 01:06 +0000 |
| Message-ID | <KqrWF.100712$UPz1.15399@fx15.am4> |
| In reply to | #71519 |
On 22/01/2020 19:04, Christian Gollwitzer wrote:
> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org:
>> I have paint to watch drying instead.
> Nice idiom
>
>> No doubt it comes from the same ivory
>> tower that claims gotos should never be used.
>>
>
> Ivory tower, for sure? We have while, for, break, continue, return, and
> exceptions. All these compile to some sort of goto in machine code.
>
> What good reasons are left for a literal goto? I can see it in C for
> error handling (because it lacks exceptions) - in C++ there is hardly a
> good reason IMHO.
>
(Copied from a post elsewhere)
I still use it [goto], although rarely. For example:
For temporary code, until it can be done properly
To temporarily by-pass code or to cut to the action for debugging
When translating an algorithm or code from another language, that
itself uses goto
When using this language as a target language for another, and I
need goto to emulate the control flow of a statement that has no
direct equivalent
To implement state machines
Via inline assembly, to deal with error recovery across functions
(although it's a long time since I used that); but also to implement
threaded code in interpreters
Or just when I can't be bothered with too-convoluted code, and goto
is the fastest and simplest way of expressing my intent
Even with this, I think my incidence of using goto is once per 400 lines
or so, so 'spaghetti code' is unlikely.
I would not design a new language without goto.
[toc] | [prev] | [next] | [standalone]
| From | Bo Persson <bo@bo-persson.se> |
|---|---|
| Date | 2020-01-24 10:07 +0100 |
| Message-ID | <h8vqe4Fiqq9U1@mid.individual.net> |
| In reply to | #71533 |
On 2020-01-24 at 02:06, Bart wrote:
> On 22/01/2020 19:04, Christian Gollwitzer wrote:
>> Am 22.01.20 um 12:26 schrieb boltar@nowhere.org:
>>> I have paint to watch drying instead.
>> Nice idiom
>>
>>> No doubt it comes from the same ivory
>>> tower that claims gotos should never be used.
>>>
>>
>> Ivory tower, for sure? We have while, for, break, continue, return,
>> and exceptions. All these compile to some sort of goto in machine code.
>>
>> What good reasons are left for a literal goto? I can see it in C for
>> error handling (because it lacks exceptions) - in C++ there is hardly
>> a good reason IMHO.
>>
>
> (Copied from a post elsewhere)
>
> I still use it [goto], although rarely. For example:
>
> For temporary code, until it can be done properly
>
> To temporarily by-pass code or to cut to the action for debugging
>
> When translating an algorithm or code from another language, that
> itself uses goto
>
> When using this language as a target language for another, and I
> need goto to emulate the control flow of a statement that has no
> direct equivalent
>
> To implement state machines
>
> Via inline assembly, to deal with error recovery across functions
> (although it's a long time since I used that); but also to implement
> threaded code in interpreters
>
> Or just when I can't be bothered with too-convoluted code, and goto
> is the fastest and simplest way of expressing my intent
>
> Even with this, I think my incidence of using goto is once per 400 lines
> or so, so 'spaghetti code' is unlikely.
>
I find that an extremely high use of goto. Would rather expect once in a
million lines, or so.
Bo Persson
[toc] | [prev] | [next] | [standalone]
Page 6 of 11 — ← Prev page 1 … 4 5 [6] 7 8 … 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web