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 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
| From | Chris Vine <chris@cvine--nospam--.freeserve.co.uk> |
|---|---|
| Date | 2020-01-25 13:42 +0000 |
| Message-ID | <20200125134202.8939b7b4f1db1e1f59c1411d@cvine--nospam--.freeserve.co.uk> |
| In reply to | #71567 |
On Sat, 25 Jan 2020 11:57:24 +0000 Bart <bc@freeuk.com> wrote: > On 25/01/2020 06:50, Ian Collins wrote: > > On 25/01/2020 14:19, Bart wrote: > > > >> I can only repeat that the Linux kernel seems to use a lot, about > >> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only). > >> > >> That's a frequency of once every 152 or 117 lines. > > > > That's also C. > > David Brown said: > > "I can only ever remember /once/ using "goto" in C code..." And you said: "Or C++; as I said earlier, it's not clear how much C++ helps avoiding gotos compared with C. C++-style exceptions would be handled by longjmp in C? Then that wouldn't count as a goto." The point you were missing, and still seem to be missing, is that C++'s RAII (which caters for early returns) dispenses with the need to use goto's and labels for implementing what amounts to finally clauses in C, which is probably its most common usage in the linux kernel.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 14:58 +0000 |
| Message-ID | <zIYWF.84332$iK5.17923@fx34.am4> |
| In reply to | #71569 |
On 25/01/2020 13:42, Chris Vine wrote:
> On Sat, 25 Jan 2020 11:57:24 +0000
> Bart <bc@freeuk.com> wrote:
>> David Brown said:
>>
>> "I can only ever remember /once/ using "goto" in C code..."
>
> And you said:
>
> "Or C++; as I said earlier, it's not clear how much C++ helps avoiding
> gotos compared with C. C++-style exceptions would be handled by longjmp
> in C? Then that wouldn't count as a goto."
>
> The point you were missing, and still seem to be missing, is that C++'s
> RAII (which caters for early returns) dispenses with the need to use
> goto's and labels for implementing what amounts to finally clauses in C,
> which is probably its most common usage in the linux kernel.
>
I chose one random file, workqueue.c, and scanned a few gotos. They
seemed to be backward jumps. For example:
reflush:
flush_workqueue(wq);
mutex_lock(&wq->mutex);
for_each_pwq(pwq, wq) {
bool drained;
spin_lock_irq(&pwq->pool->lock);
drained = !pwq->nr_active && list_empty(&pwq->delayed_works);
spin_unlock_irq(&pwq->pool->lock);
if (drained)
continue;
if (++flush_cnt == 10 ||
(flush_cnt % 100 == 0 && flush_cnt <= 1000))
pr_warn("workqueue %s: drain_workqueue() isn't complete after %u
tries\n",
wq->name, flush_cnt);
mutex_unlock(&wq->mutex);
goto reflush;
}
This looks like it really needs two nested loops rather than one, but
probably requires nested loop controls, so means extra flags.
How would C++ help here, to avoid either that extra logic, or the use of
that goto? Here's the current outline (for_each_pwq is a macro expanding
to a regular for-header):
L:
A;
for (...) {
B;
if (C) continue;
D;
goto L;
}
This can be done without gotos and without additional logic in my own
language, as it supports nested loop controls:
do
A
for ... do
B
if C then next fi # next=continue, sort of
D
redo all # restart outer loop body
end
exit # exit=break
end
(Another way is for the outer loop to be 'to 1 do', execute once, to
avoid that exit.)
So I genuinely have features to help cut back on use of goto, yet I
still use goto because, as I said, I mainly use it for share code
fragments within a function.
(I then looked at one more example, which was this (umh.c), here only
outlined:
...
if (A) {
B;
if (C) {
D;
goto L;
}
}
E;
L:
G;
} // end of function
Any ideas? This one seems more about code-sharing. I'm still interested
in any C++ magic to help out. Rewriting 25MLoC is not a helpful
suggestion...)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-26 07:58 +1300 |
| Message-ID | <h93hf2F25s3U8@mid.individual.net> |
| In reply to | #71570 |
On 26/01/2020 03:58, Bart wrote:
> On 25/01/2020 13:42, Chris Vine wrote:
>> On Sat, 25 Jan 2020 11:57:24 +0000
>> Bart <bc@freeuk.com> wrote:
>
>>> David Brown said:
>>>
>>> "I can only ever remember /once/ using "goto" in C code..."
>>
>> And you said:
>>
>> "Or C++; as I said earlier, it's not clear how much C++ helps avoiding
>> gotos compared with C. C++-style exceptions would be handled by longjmp
>> in C? Then that wouldn't count as a goto."
>>
>> The point you were missing, and still seem to be missing, is that C++'s
>> RAII (which caters for early returns) dispenses with the need to use
>> goto's and labels for implementing what amounts to finally clauses in C,
>> which is probably its most common usage in the linux kernel.
>>
>
> I chose one random file, workqueue.c, and scanned a few gotos. They
> seemed to be backward jumps. For example:
>
> reflush:
> flush_workqueue(wq);
>
> mutex_lock(&wq->mutex);
>
> for_each_pwq(pwq, wq) {
> bool drained;
>
> spin_lock_irq(&pwq->pool->lock);
> drained = !pwq->nr_active && list_empty(&pwq->delayed_works);
> spin_unlock_irq(&pwq->pool->lock);
>
> if (drained)
> continue;
>
> if (++flush_cnt == 10 ||
> (flush_cnt % 100 == 0 && flush_cnt <= 1000))
> pr_warn("workqueue %s: drain_workqueue() isn't complete after %u
> tries\n",
> wq->name, flush_cnt);
>
> mutex_unlock(&wq->mutex);
> goto reflush;
> }
>
> This looks like it really needs two nested loops rather than one, but
> probably requires nested loop controls, so means extra flags.
As you say, just using two loops, possibly extracting the logic in the
last if the to a function to use as the loop control, would be an
appropriate fix. This is just a matter of style, not C or C++.
You can pick a "random" file to show pretty much any form of dodgy
coding in the kernel code base! That doesn't change the fact that the
most common use of got in C code is, as Chris suggests, implementing
what amounts to finally clauses. C++ doesn't need them.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-01-25 20:34 +0100 |
| Message-ID | <r0i57p$20o$1@dont-email.me> |
| In reply to | #71570 |
On 25/01/2020 15:58, Bart wrote:
> On 25/01/2020 13:42, Chris Vine wrote:
>> On Sat, 25 Jan 2020 11:57:24 +0000
>> Bart <bc@freeuk.com> wrote:
>
>>> David Brown said:
>>>
>>> "I can only ever remember /once/ using "goto" in C code..."
>>
>> And you said:
>>
>> "Or C++; as I said earlier, it's not clear how much C++ helps avoiding
>> gotos compared with C. C++-style exceptions would be handled by longjmp
>> in C? Then that wouldn't count as a goto."
>>
>> The point you were missing, and still seem to be missing, is that C++'s
>> RAII (which caters for early returns) dispenses with the need to use
>> goto's and labels for implementing what amounts to finally clauses in C,
>> which is probably its most common usage in the linux kernel.
>>
>
> I chose one random file, workqueue.c, and scanned a few gotos. They
> seemed to be backward jumps. For example:
>
> reflush:
> flush_workqueue(wq);
>
> mutex_lock(&wq->mutex);
>
> for_each_pwq(pwq, wq) {
> bool drained;
>
> spin_lock_irq(&pwq->pool->lock);
> drained = !pwq->nr_active && list_empty(&pwq->delayed_works);
> spin_unlock_irq(&pwq->pool->lock);
>
> if (drained)
> continue;
>
> if (++flush_cnt == 10 ||
> (flush_cnt % 100 == 0 && flush_cnt <= 1000))
> pr_warn("workqueue %s: drain_workqueue() isn't complete
> after %u tries\n",
> wq->name, flush_cnt);
>
> mutex_unlock(&wq->mutex);
> goto reflush;
> }
>
> This looks like it really needs two nested loops rather than one, but
> probably requires nested loop controls, so means extra flags.
>
> How would C++ help here, to avoid either that extra logic, or the use of
> that goto? Here's the current outline (for_each_pwq is a macro expanding
> to a regular for-header):
>
> L:
> A;
> for (...) {
> B;
> if (C) continue;
> D;
> goto L;
> }
I'm not sure how C++ would help here - you can write horrible
unstructured code in most languages. (C++ is a bit more restrictive in
how much you can jump around in unstructured ways, but I don't think it
stops this one.) What /would/ help is to give the programmer a good
kick up the arse and send him back to try again. (Having a resource
acquisition and release, like the mutex lock, at different levels of
indentation is a sure sign of jumbled thinking.)
do {
bool reflush = false;
A;
for (...) {
B;
if (!C) {
D;
reflush = true;
break;
}
}
}
Maybe the structure should be a little different - I haven't thought
through the details (and in particular, I don't know the "for_each_pwq"
macro). But a boolean flag like this is free - the compiler will turn
it into a goto.
>
> This can be done without gotos and without additional logic in my own
> language, as it supports nested loop controls:
>
> do
> A
> for ... do
> B
> if C then next fi # next=continue, sort of
> D
> redo all # restart outer loop body
> end
> exit # exit=break
> end
>
> (Another way is for the outer loop to be 'to 1 do', execute once, to
> avoid that exit.)
>
> So I genuinely have features to help cut back on use of goto, yet I
> still use goto because, as I said, I mainly use it for share code
> fragments within a function.
>
> (I then looked at one more example, which was this (umh.c), here only
> outlined:
>
> ...
> if (A) {
> B;
> if (C) {
> D;
> goto L;
> }
> }
>
> E;
> L:
> G;
> } // end of function
>
> Any ideas? This one seems more about code-sharing. I'm still interested
> in any C++ magic to help out. Rewriting 25MLoC is not a helpful
> suggestion...)
> ...
bool skip_e = false;
> if (A) {
> B;
> if (C) {
> D;
> skip_e = true;
> }
> }
>
if (!skip_e) {
> E;
}
> L:
> G;
There is nothing like this that can't be handled by a flag boolean or
two. But there might be better ways, depending on the details of the
code - including splitting things up into more than one function,
duplicating code, or other re-arrangements.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-01-25 12:41 -0800 |
| Message-ID | <13fd1339-8eb6-4b9c-809b-0a143987a95f@googlegroups.com> |
| In reply to | #71570 |
On Saturday, 25 January 2020 16:58:49 UTC+2, Bart wrote:
...
> How would C++ help here, to avoid either that extra logic, or the use of
> that goto?
Actually C has quite sophisticated program flow control to what C++
basically adds only exceptions and destructors plus various cosmetics
like range based fors and lambdas.
> Here's the current outline (for_each_pwq is a macro expanding
> to a regular for-header):
>
> L:
> A;
> for (...) {
> B;
> if (C) continue;
> D;
> goto L;
> }
Lets say for(...) above is for(E;F;G) then:
do {
A;
for (E;F;G) {
B;
if (!C) {
D;
break;
}
}
} while (F);
But I would no refactor it unless there is some kind of need
because it just adds another check of F.
> (I then looked at one more example, which was this (umh.c), here only
> outlined:
>
> ...
> if (A) {
> B;
> if (C) {
> D;
> goto L;
> }
> }
>
> E;
> L:
> G;
> } // end of function
Here if G is done by destructor it is basically:
if (A) {
B;
if (C) {
D;
return;
}
}
E;
} // end of function
>
> Any ideas? This one seems more about code-sharing. I'm still interested
> in any C++ magic to help out. Rewriting 25MLoC is not a helpful
> suggestion...)
There are no magic. It matters if we want the G to
be ran even when something else, like B, throws, then
the G should be in destructor in C++. Otherwise it is
a bug waiting to start manifesting.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-26 16:08 +0200 |
| Message-ID | <r0k6ga$6ue$1@dont-email.me> |
| In reply to | #71570 |
On 25.01.2020 16:58, Bart wrote:
> How would C++ help here, to avoid either that extra logic, or the use of
> that goto? Here's the current outline (for_each_pwq is a macro expanding
> to a regular for-header):
>
> L:
> A;
> for (...) {
> B;
> if (C) continue;
> D;
> goto L;
> }
This is an example of some pretty convoluted logic, not even because of
'goto', but rather because of multiple code execution paths (two
non-default exit paths from inner loop body and no normal exit path). I
would rewrite this along the lines:
bool foobar(...) {
for (...) {
B;
if (!C) {
D;
return false;
}
}
return true;
}
while (true) {
A;
if (foobar(...)) {
break;
}
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-01-27 02:20 -0800 |
| Message-ID | <86r1zlgpyx.fsf@linuxsc.com> |
| In reply to | #71593 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> On 25.01.2020 16:58, Bart wrote:
>
>> How would C++ help here, to avoid either that extra logic, or the use of
>> that goto? Here's the current outline (for_each_pwq is a macro expanding
>> to a regular for-header):
>>
>> L:
>> A;
>> for (...) {
>> B;
>> if (C) continue;
>> D;
>> goto L;
>> }
>
> This is an example of some pretty convoluted logic, not even because
> of 'goto', but rather because of multiple code execution paths (two
> non-default exit paths from inner loop body and no normal exit
> path). I would rewrite this along the lines:
>
> bool foobar(...) {
> for (...) {
> B;
> if (!C) {
> D;
> return false;
> }
> }
> return true;
> }
>
> while (true) {
> A;
> if (foobar(...)) {
> break;
> }
> }
To me this alternative is worse than the original. Just a
personal reaction. To give the peanut gallery something to hoot
about, and fya, the code (in C++!) may be recast as follows:
void
funky(){
A;
for (...) {
B;
if (C) continue;
D;
return funky();
}
}
(Let me say in advance I will disregard any sort of heated
discussion about the inadvisability of the self-recursion
here. I know a lot of people don't like it. Get over it.)
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-01-27 15:03 +0200 |
| Message-ID | <r0mn3f$gml$1@dont-email.me> |
| In reply to | #71621 |
On 27.01.2020 12:20, Tim Rentsch wrote:
> Paavo Helde <myfirstname@osa.pri.ee> writes:
>
>> On 25.01.2020 16:58, Bart wrote:
>>
>>> How would C++ help here, to avoid either that extra logic, or the use of
>>> that goto? Here's the current outline (for_each_pwq is a macro expanding
>>> to a regular for-header):
>>>
>>> L:
>>> A;
>>> for (...) {
>>> B;
>>> if (C) continue;
>>> D;
>>> goto L;
>>> }
>>
>> This is an example of some pretty convoluted logic, not even because
>> of 'goto', but rather because of multiple code execution paths (two
>> non-default exit paths from inner loop body and no normal exit
>> path). I would rewrite this along the lines:
>>
>> bool foobar(...) {
>> for (...) {
>> B;
>> if (!C) {
>> D;
>> return false;
>> }
>> }
>> return true;
>> }
>>
>> while (true) {
>> A;
>> if (foobar(...)) {
>> break;
>> }
>> }
>
> To me this alternative is worse than the original. Just a
> personal reaction.
Yes, must be personal...
> To give the peanut gallery something to hoot
> about, and fya, the code (in C++!) may be recast as follows:
>
> void
> funky(){
> A;
> for (...) {
> B;
> if (C) continue;
> D;
> return funky();
> }
> }
>
With the original example, this rewrite would be valid in C where 'A;'
contained mutex locking and 'D;' contained mutex unlocking code.
However, in C++ where the lock would be presumable implemented as an
RAII class, the recursive call would not work any more. The mutex might
not support recursive locking, and even if it does, the recursive call
would call first part of A ('flush_workqueue(wq);') under the mutex
lock, which would be all wrong I suspect.
So, is this a case where using a 'goto' would be in some sense more
justified in C++ than in C?
BTW, in my own code I have several times encountered similar awkward
"backward goto" scenarios needed only for unlocking a mutex. And the
result has always been a mess I'm afraid.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-02-15 06:44 -0800 |
| Message-ID | <865zg7hpux.fsf@linuxsc.com> |
| In reply to | #71623 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> On 27.01.2020 12:20, Tim Rentsch wrote:
>
>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>
>>> On 25.01.2020 16:58, Bart wrote:
>>>
>>>> How would C++ help here, to avoid either that extra logic, or the use of
>>>> that goto? Here's the current outline (for_each_pwq is a macro expanding
>>>> to a regular for-header):
>>>>
>>>> L:
>>>> A;
>>>> for (...) {
>>>> B;
>>>> if (C) continue;
>>>> D;
>>>> goto L;
>>>> }
>>>
>>> This is an example of some pretty convoluted logic, not even because
>>> of 'goto', but rather because of multiple code execution paths (two
>>> non-default exit paths from inner loop body and no normal exit
>>> path). I would rewrite this along the lines:
>>>
>>> bool foobar(...) {
>>> for (...) {
>>> B;
>>> if (!C) {
>>> D;
>>> return false;
>>> }
>>> }
>>> return true;
>>> }
>>>
>>> while (true) {
>>> A;
>>> if (foobar(...)) {
>>> break;
>>> }
>>> }
>>
>> To me this alternative is worse than the original. Just a
>> personal reaction.
>
> Yes, must be personal...
I meant only that I am representing only my own viewpoint.
Did you think I meant something else?
>> To give the peanut gallery something to hoot
>> about, and fya, the code (in C++!) may be recast as follows:
>>
>> void
>> funky(){
>> A;
>> for (...) {
>> B;
>> if (C) continue;
>> D;
>> return funky();
>> }
>> }
>
> With the original example, this rewrite would be valid in C where 'A;'
> contained mutex locking and 'D;' contained mutex unlocking code.
Yes, I was talking about such cases.
> However, in C++ where the lock would be presumable implemented as an
> RAII class, the recursive call would not work any more. The mutex
> might not support recursive locking, and even if it does, the
> recursive call would call first part of A ('flush_workqueue(wq);')
> under the mutex lock, which would be all wrong I suspect.
Right. When there is behavior resulting from destructor calls, trying
to use (what looks like) a recursive tail call is very likely a bad
idea even if it isn't outright wrong, which it certainly could be.
> So, is this a case where using a 'goto' would be in some sense more
> justified in C++ than in C?
I think I would say using a 'goto' is more likely to be justifiable
in cases like this one (that is, more likely in C++ than in C). It
may be that there are other ways of coding the needed functionality
that do not use a 'goto'. But considering that pending destructor
behavior can eliminate this one alternative, it looks like C has an
option available that C++ does not, at least not in practical terms.
And that could result in using a 'goto' being the most attractive
alternative available in C++ but not in C.
> BTW, in my own code I have several times encountered similar awkward
> "backward goto" scenarios needed only for unlocking a mutex. And the
> result has always been a mess I'm afraid.
That's interesting. Is that always because of pending destructor
behavior? If it is, that suggests that the RAII pattern using
standard constructor/destructor semantics has some shortcomings,
which may indicate a need for other behavior choices. For example,
the funky() function above could be writeable using a new 'creturn'
construct, written as
creturn funky();
where 'creturn' means first run any pending destructors, and only
after they finish execute the (implied) return statement. Doing
that avoids all the nested locking problems, and also makes the
apparent "tail call" be a true tail call, and so could be optimized
to reuse the stack frame. What other kinds of constructs might make
your troublesome mutex uses more tractable?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-03-06 10:18 +0200 |
| Message-ID | <r3t10p$mt3$1@dont-email.me> |
| In reply to | #71858 |
On 15.02.2020 16:44, Tim Rentsch wrote:
> Paavo Helde <myfirstname@osa.pri.ee> writes:
>
>> On 27.01.2020 12:20, Tim Rentsch wrote:
>>
>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>
>>>> On 25.01.2020 16:58, Bart wrote:
>>>>
>>>>> How would C++ help here, to avoid either that extra logic, or the use of
>>>>> that goto? Here's the current outline (for_each_pwq is a macro expanding
>>>>> to a regular for-header):
>>>>>
>>>>> L:
>>>>> A;
>>>>> for (...) {
>>>>> B;
>>>>> if (C) continue;
>>>>> D;
>>>>> goto L;
>>>>> }
>>>>
>>>> This is an example of some pretty convoluted logic, not even because
>>>> of 'goto', but rather because of multiple code execution paths (two
>>>> non-default exit paths from inner loop body and no normal exit
>>>> path). I would rewrite this along the lines:
>>>>
>>>> bool foobar(...) {
>>>> for (...) {
>>>> B;
>>>> if (!C) {
>>>> D;
>>>> return false;
>>>> }
>>>> }
>>>> return true;
>>>> }
>>>>
>>>> while (true) {
>>>> A;
>>>> if (foobar(...)) {
>>>> break;
>>>> }
>>>> }
>>>
>>> To me this alternative is worse than the original. Just a
>>> personal reaction.
>>
>> Yes, must be personal...
>
> I meant only that I am representing only my own viewpoint.
> Did you think I meant something else?
No, I also just meant a personal viewpoint. To be honest, I'm not sure
any more which version I dislike more.
>
>>> To give the peanut gallery something to hoot
>>> about, and fya, the code (in C++!) may be recast as follows:
>>>
>>> void
>>> funky(){
>>> A;
>>> for (...) {
>>> B;
>>> if (C) continue;
>>> D;
>>> return funky();
>>> }
>>> }
>>
>> With the original example, this rewrite would be valid in C where 'A;'
>> contained mutex locking and 'D;' contained mutex unlocking code.
>
> Yes, I was talking about such cases.
>
>> However, in C++ where the lock would be presumable implemented as an
>> RAII class, the recursive call would not work any more. The mutex
>> might not support recursive locking, and even if it does, the
>> recursive call would call first part of A ('flush_workqueue(wq);')
>> under the mutex lock, which would be all wrong I suspect.
>
> Right. When there is behavior resulting from destructor calls, trying
> to use (what looks like) a recursive tail call is very likely a bad
> idea even if it isn't outright wrong, which it certainly could be.
>
>> So, is this a case where using a 'goto' would be in some sense more
>> justified in C++ than in C?
>
> I think I would say using a 'goto' is more likely to be justifiable
> in cases like this one (that is, more likely in C++ than in C). It
> may be that there are other ways of coding the needed functionality
> that do not use a 'goto'. But considering that pending destructor
> behavior can eliminate this one alternative, it looks like C has an
> option available that C++ does not, at least not in practical terms.
> And that could result in using a 'goto' being the most attractive
> alternative available in C++ but not in C.
>
>> BTW, in my own code I have several times encountered similar awkward
>> "backward goto" scenarios needed only for unlocking a mutex. And the
>> result has always been a mess I'm afraid.
>
> That's interesting. Is that always because of pending destructor
> behavior? If it is, that suggests that the RAII pattern using
> standard constructor/destructor semantics has some shortcomings,
> which may indicate a need for other behavior choices. For example,
> the funky() function above could be writeable using a new 'creturn'
> construct, written as
>
> creturn funky();
>
> where 'creturn' means first run any pending destructors, and only
> after they finish execute the (implied) return statement.
This would mess up the lifetime rules of automatic variables, meaning
that their lifetime would not match the visual scope any more. I'm sure
this would do more harm than good.
Also, such 'creturn' would not solve the initial problems, at least not
in cases I have had. Effectively, what is needed is to release a mutex
lock temporarily in some circumstances, do something out of the mutex
lock, then enter the lock again. Logically this is a task for a single
function, any 'return' or 'creturn' would split this task into two
functions, which is a bit convoluted, which I think you already
mentioned above.
> Doing
> that avoids all the nested locking problems, and also makes the
> apparent "tail call" be a true tail call, and so could be optimized
> to reuse the stack frame. What other kinds of constructs might make
> your troublesome mutex uses more tractable?
>
What would help in my case would be a command like 'retry' or 'restart'
which would destroy all automatic variables in the function and restart
the function again. It would be equivalent to a 'goto' to a label in the
start of the function, with the only benefit that the jump destination
is more fixed than with a regular goto. Not sure if this would be worth
it, especially when considering that in some other closely related
scenarios one might want to keep some variables intact.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-02 07:05 -0700 |
| Message-ID | <86mu7u6kzx.fsf@linuxsc.com> |
| In reply to | #72122 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> On 15.02.2020 16:44, Tim Rentsch wrote:
>
>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>
>>> On 27.01.2020 12:20, Tim Rentsch wrote:
>>>
>>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>>
>>>>> On 25.01.2020 16:58, Bart wrote:
>>>>>
>>>>>> How would C++ help here, to avoid either that extra logic, or
>>>>>> the use of that goto? Here's the current outline (for_each_pwq
>>>>>> is a macro expanding to a regular for-header):
>>>>>>
>>>>>> L:
>>>>>> A;
>>>>>> for (...) {
>>>>>> B;
>>>>>> if (C) continue;
>>>>>> D;
>>>>>> goto L;
>>>>>> }
[...]
>>> BTW, in my own code I have several times encountered similar awkward
>>> "backward goto" scenarios needed only for unlocking a mutex. And the
>>> result has always been a mess I'm afraid.
>>
>> That's interesting. Is that always because of pending destructor
>> behavior? If it is, that suggests that the RAII pattern using
>> standard constructor/destructor semantics has some shortcomings,
>> which may indicate a need for other behavior choices. For example,
>> the funky() function above could be writeable using a new 'creturn'
>> construct, written as
>>
>> creturn funky();
>>
>> where 'creturn' means first run any pending destructors, and only
>> after they finish execute the (implied) return statement.
>
> This would mess up the lifetime rules of automatic variables, meaning
> that their lifetime would not match the visual scope any more. I'm
> sure this would do more harm than good.
>
> Also, such 'creturn' would not solve the initial problems, at least
> not in cases I have had. Effectively, what is needed is to release a
> mutex lock temporarily in some circumstances, do something out of the
> mutex lock, then enter the lock again. Logically this is a task for a
> single function, any 'return' or 'creturn' would split this task into
> two functions, which is a bit convoluted, which I think you already
> mentioned above.
>
>
>> Doing
>> that avoids all the nested locking problems, and also makes the
>> apparent "tail call" be a true tail call, and so could be optimized
>> to reuse the stack frame. What other kinds of constructs might make
>> your troublesome mutex uses more tractable?
>
> What would help in my case would be a command like 'retry' or
> restart' which would destroy all automatic variables in the function
> and restart the function again. It would be equivalent to a 'goto' to
> a label in the start of the function, [...]
It is rather amusing that you didn't like creturn, and then
describe a construct that behaves just the way a creturn would,
except the retry/restart construct is less general than creturn.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <myfirstname@osa.pri.ee> |
|---|---|
| Date | 2020-04-02 20:03 +0300 |
| Message-ID | <r655s9$7oj$1@dont-email.me> |
| In reply to | #72751 |
On 2.04.2020 17:05, Tim Rentsch wrote:
> Paavo Helde <myfirstname@osa.pri.ee> writes:
>
>> On 15.02.2020 16:44, Tim Rentsch wrote:
>>
>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>
>>>> On 27.01.2020 12:20, Tim Rentsch wrote:
>>>>
>>>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>>>
>>>>>> On 25.01.2020 16:58, Bart wrote:
>>>>>>
>>>>>>> How would C++ help here, to avoid either that extra logic, or
>>>>>>> the use of that goto? Here's the current outline (for_each_pwq
>>>>>>> is a macro expanding to a regular for-header):
>>>>>>>
>>>>>>> L:
>>>>>>> A;
>>>>>>> for (...) {
>>>>>>> B;
>>>>>>> if (C) continue;
>>>>>>> D;
>>>>>>> goto L;
>>>>>>> }
>
> [...]
>
>>>> BTW, in my own code I have several times encountered similar awkward
>>>> "backward goto" scenarios needed only for unlocking a mutex. And the
>>>> result has always been a mess I'm afraid.
>>>
>>> That's interesting. Is that always because of pending destructor
>>> behavior? If it is, that suggests that the RAII pattern using
>>> standard constructor/destructor semantics has some shortcomings,
>>> which may indicate a need for other behavior choices. For example,
>>> the funky() function above could be writeable using a new 'creturn'
>>> construct, written as
>>>
>>> creturn funky();
>>>
>>> where 'creturn' means first run any pending destructors, and only
>>> after they finish execute the (implied) return statement.
>>
>> This would mess up the lifetime rules of automatic variables, meaning
>> that their lifetime would not match the visual scope any more. I'm
>> sure this would do more harm than good.
>>
>> Also, such 'creturn' would not solve the initial problems, at least
>> not in cases I have had. Effectively, what is needed is to release a
>> mutex lock temporarily in some circumstances, do something out of the
>> mutex lock, then enter the lock again. Logically this is a task for a
>> single function, any 'return' or 'creturn' would split this task into
>> two functions, which is a bit convoluted, which I think you already
>> mentioned above.
>>
>>
>>> Doing
>>> that avoids all the nested locking problems, and also makes the
>>> apparent "tail call" be a true tail call, and so could be optimized
>>> to reuse the stack frame. What other kinds of constructs might make
>>> your troublesome mutex uses more tractable?
>>
>> What would help in my case would be a command like 'retry' or
>> restart' which would destroy all automatic variables in the function
>> and restart the function again. It would be equivalent to a 'goto' to
>> a label in the start of the function, [...]
>
> It is rather amusing that you didn't like creturn, and then
> describe a construct that behaves just the way a creturn would,
> except the retry/restart construct is less general than creturn.
That's because the main problem with the current solution (goto) is that
it is too general. That's the reason why more restricted statements
(break and continue) exist even though they could be replaced by goto-s.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-04-04 12:37 -0700 |
| Message-ID | <86o8s7nit1.fsf@linuxsc.com> |
| In reply to | #72757 |
Paavo Helde <myfirstname@osa.pri.ee> writes:
> On 2.04.2020 17:05, Tim Rentsch wrote:
>
>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>
>>> On 15.02.2020 16:44, Tim Rentsch wrote:
>>>
>>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>>
>>>>> On 27.01.2020 12:20, Tim Rentsch wrote:
>>>>>
>>>>>> Paavo Helde <myfirstname@osa.pri.ee> writes:
>>>>>>
>>>>>>> On 25.01.2020 16:58, Bart wrote:
>>>>>>>
>>>>>>>> How would C++ help here, to avoid either that extra logic, or
>>>>>>>> the use of that goto? Here's the current outline (for_each_pwq
>>>>>>>> is a macro expanding to a regular for-header):
>>>>>>>>
>>>>>>>> L:
>>>>>>>> A;
>>>>>>>> for (...) {
>>>>>>>> B;
>>>>>>>> if (C) continue;
>>>>>>>> D;
>>>>>>>> goto L;
>>>>>>>> }
>>
>> [...]
>>
>>>>> BTW, in my own code I have several times encountered similar awkward
>>>>> "backward goto" scenarios needed only for unlocking a mutex. And the
>>>>> result has always been a mess I'm afraid.
>>>>
>>>> That's interesting. Is that always because of pending destructor
>>>> behavior? If it is, that suggests that the RAII pattern using
>>>> standard constructor/destructor semantics has some shortcomings,
>>>> which may indicate a need for other behavior choices. For example,
>>>> the funky() function above could be writeable using a new 'creturn'
>>>> construct, written as
>>>>
>>>> creturn funky();
>>>>
>>>> where 'creturn' means first run any pending destructors, and only
>>>> after they finish execute the (implied) return statement.
>>>
>>> This would mess up the lifetime rules of automatic variables, meaning
>>> that their lifetime would not match the visual scope any more. I'm
>>> sure this would do more harm than good.
>>>
>>> Also, such 'creturn' would not solve the initial problems, at least
>>> not in cases I have had. Effectively, what is needed is to release a
>>> mutex lock temporarily in some circumstances, do something out of the
>>> mutex lock, then enter the lock again. Logically this is a task for a
>>> single function, any 'return' or 'creturn' would split this task into
>>> two functions, which is a bit convoluted, which I think you already
>>> mentioned above.
>>>
>>>
>>>> Doing
>>>> that avoids all the nested locking problems, and also makes the
>>>> apparent "tail call" be a true tail call, and so could be optimized
>>>> to reuse the stack frame. What other kinds of constructs might make
>>>> your troublesome mutex uses more tractable?
>>>
>>> What would help in my case would be a command like 'retry' or
>>> restart' which would destroy all automatic variables in the function
>>> and restart the function again. It would be equivalent to a 'goto' to
>>> a label in the start of the function, [...]
>>
>> It is rather amusing that you didn't like creturn, and then
>> describe a construct that behaves just the way a creturn would,
>> except the retry/restart construct is less general than creturn.
>
> That's because the main problem with the current solution (goto) is
> that it is too general. That's the reason why more restricted
> statements (break and continue) exist even though they could be
> replaced by goto-s.
goto is unstructured. return (and creturn) is structured.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-26 07:45 +1300 |
| Message-ID | <h93gm8F25s3U7@mid.individual.net> |
| In reply to | #71567 |
On 26/01/2020 00:57, Bart wrote: > On 25/01/2020 06:50, Ian Collins wrote: >> On 25/01/2020 14:19, Bart wrote: >> >>> I can only repeat that the Linux kernel seems to use a lot, about >>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only). >>> >>> That's a frequency of once every 152 or 117 lines. >> >> That's also C. > > David Brown said: > > "I can only ever remember /once/ using "goto" in C code..." You asked the question, which you have snipped: "Or C++; as I said earlier, it's not clear how much C++ helps avoiding gotos compared with C." What do you have to say about my answer? -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 19:56 +0000 |
| Message-ID | <h41XF.367918$Arx.178294@fx08.am4> |
| In reply to | #71571 |
On 25/01/2020 18:45, Ian Collins wrote:
> On 26/01/2020 00:57, Bart wrote:
>> On 25/01/2020 06:50, Ian Collins wrote:
>>> On 25/01/2020 14:19, Bart wrote:
>>>
>>>> I can only repeat that the Linux kernel seems to use a lot, about
>>>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only).
>>>>
>>>> That's a frequency of once every 152 or 117 lines.
>>>
>>> That's also C.
>>
>> David Brown said:
>>
>> "I can only ever remember /once/ using "goto" in C code..."
>
> You asked the question, which you have snipped: "Or C++; as I said
> earlier, it's not clear how much C++ helps avoiding gotos compared with C."
>
> What do you have to say about my answer?
>
If DB can avoid using 'goto' in C for (I understand) several decades,
then he can do it for C++ too.
The purpose of my mentioning Linux sources is that there are a range of
programming styles even in C: Linux kernel may be a prolific user of
gotos, DB is at the other end of the scale, and I would say extreme
(actually you can't be more extreme without using a negative number of
gotos!).
I'm not convinced that C++ features such RAII, exceptions, destructors
and so on are enough to deal with all the use-cases of goto I listed
earlier in the sub-thread, or the ones I didn't think of.
So they cannot by themselves account for using for being able to use 0
gotos. It seems some people just don't like them, and go to extra
measures to avoid them. Note the word 'extra'.
BTW C, and by extension C++, contains flow control that IMO can be even
worse that goto when abused. Takes this code:
int a=1;
goto L;
if (a) {
puts("A");
} else {
L:
puts("B");
}
This should print "A", but because of the jump into the block, will show
"B". This is considered bad form. But you can do exactly the same
without the goto:
int a=1;
switch (1) // any value can be used
if (a) {
puts("A");
} else {
default:
puts("B");
}
Should unstructured switch statements like this be banned? Well, that's
not possible; people still need to use switch, and they will also come
up with use-cases for weird applications of it.
With goto, at least, you know that some underhand flow control is going on!
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-26 09:49 +1300 |
| Message-ID | <h93nvkF25s3U9@mid.individual.net> |
| In reply to | #71577 |
On 26/01/2020 08:56, Bart wrote: > On 25/01/2020 18:45, Ian Collins wrote: >> On 26/01/2020 00:57, Bart wrote: >>> On 25/01/2020 06:50, Ian Collins wrote: >>>> On 25/01/2020 14:19, Bart wrote: >>>> >>>>> I can only repeat that the Linux kernel seems to use a lot, about >>>>> 163,000 gotos in 25Mloc (including headers) or 19Mloc (.c files only). >>>>> >>>>> That's a frequency of once every 152 or 117 lines. >>>> >>>> That's also C. >>> >>> David Brown said: >>> >>> "I can only ever remember /once/ using "goto" in C code..." >> >> You asked the question, which you have snipped: "Or C++; as I said >> earlier, it's not clear how much C++ helps avoiding gotos compared with C." >> >> What do you have to say about my answer? >> > > If DB can avoid using 'goto' in C for (I understand) several decades, > then he can do it for C++ too. I have also never knowingly used goto in C or C++ code. > The purpose of my mentioning Linux sources is that there are a range of > programming styles even in C: Linux kernel may be a prolific user of > gotos, DB is at the other end of the scale, and I would say extreme > (actually you can't be more extreme without using a negative number of > gotos!). > > I'm not convinced that C++ features such RAII, exceptions, destructors > and so on are enough to deal with all the use-cases of goto I listed > earlier in the sub-thread, or the ones I didn't think of. The are enough to deal with the vast majority of them. Good (or some my say, obsessive) style will take care of the rest. I ran a quick line count and there are about 1.1M non-blank lines in our goto free C++ code base excluding headers which would add quite a bit more. So avoiding goto can't be that hard, can it? > So they cannot by themselves account for using for being able to use 0 > gotos. It seems some people just don't like them, and go to extra > measures to avoid them. Note the word 'extra'. > > BTW C, and by extension C++, contains flow control that IMO can be even > worse that goto when abused. You can misuse any idiom to write bad code. With goto, bad code comes naturally. -- Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 21:33 +0000 |
| Message-ID | <Gu2XF.135481$OZ3.80280@fx28.am4> |
| In reply to | #71579 |
On 25/01/2020 20:49, Ian Collins wrote:
> On 26/01/2020 08:56, Bart wrote:
>> I'm not convinced that C++ features such RAII, exceptions, destructors
>> and so on are enough to deal with all the use-cases of goto I listed
>> earlier in the sub-thread, or the ones I didn't think of.
>
> The are enough to deal with the vast majority of them. Good (or some my
> say, obsessive) style will take care of the rest. I ran a quick line
> count and there are about 1.1M non-blank lines in our goto free C++ code
> base excluding headers which would add quite a bit more. So avoiding
> goto can't be that hard, can it?
How can I respond to that?
I've already said I can't tell how much bigger, less readable, less
productive it might have been to code like that, how many extra
functions etc, compared with just using the odd goto.
For my part, I'm in a position where I can add new features [to the
langages I use] that can eliminate many of /my/ uses of goto.
Yet there are still quite a few, because it's not that easy. I'm not
preparated to sacrifice the clean lines of my code, add extra indent
levels, more functions etc just so I can say I don't use any gotos.
(Here's one recent feature that I'm trying out, based on someone's idea
in comp.lang.misc. First, the original code with goto:
case msg
when wm_syskeydown then
if wparam = vkf10 then
msg := wm_keydown
goto dokey
fi
...
when wm_keydown, wm_keyup then
dokey:
.... do other stuff with msg
And here's the same code using the 'recase' feature:
case msg
when wm_syskeydown then
if wparam = vkf10 then
msg := wm_keydown
recase wm_keydown
fi
...
when wm_keydown, wm_keyup then
.... do other stuff with msg
No 'goto' and no label. (And no extra bools, no extra indents, no extra
functions either.) But it doesn't cover all the ways that you may want
to share blocks of code in such kinds of statement. I'm still working on
an elegant way to express that that doesn't look worse than goto.)
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-26 11:00 +1300 |
| Message-ID | <h93s3jF25s3U10@mid.individual.net> |
| In reply to | #71580 |
On 26/01/2020 10:33, Bart wrote:
> On 25/01/2020 20:49, Ian Collins wrote:
>> On 26/01/2020 08:56, Bart wrote:
>
>>> I'm not convinced that C++ features such RAII, exceptions, destructors
>>> and so on are enough to deal with all the use-cases of goto I listed
>>> earlier in the sub-thread, or the ones I didn't think of.
>>
>> The are enough to deal with the vast majority of them. Good (or some my
>> say, obsessive) style will take care of the rest. I ran a quick line
>> count and there are about 1.1M non-blank lines in our goto free C++ code
>> base excluding headers which would add quite a bit more. So avoiding
>> goto can't be that hard, can it?
>
> How can I respond to that?
>
> I've already said I can't tell how much bigger, less readable, less
> productive it might have been to code like that, how many extra
> functions etc, compared with just using the odd goto.
The use of RAII generally makes the code smaller (we don't need to
repeat the deallocation code for each allocation.
As mentioned previously, most uses of goto in C kernel and driver code
is what amounts to finally clauses, freeing stuff that may have been
allocated before some error condition is detected. A classic example is
this short function from the Linux kernel source:
void vga_put(struct pci_dev *pdev, unsigned int rsrc)
{
struct vga_device *vgadev;
unsigned long flags;
/* The one who calls us should check for this, but lets be sure... */
if (pdev == NULL)
pdev = vga_default_device();
if (pdev == NULL)
return;
spin_lock_irqsave(&vga_lock, flags);
vgadev = vgadev_find(pdev);
if (vgadev == NULL)
goto bail;
__vga_put(vgadev, rsrc);
bail:
spin_unlock_irqrestore(&vga_lock, flags);
}
(https://elixir.bootlin.com/linux/latest/source/drivers/gpu/vga/vgaarb.c)
In C++, the lock would be managed so there's no need for a manual unlock
and therefore no need for the "finally" block.
--
Ian.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-01-25 22:23 +0000 |
| Message-ID | <Ed3XF.242331$_R5.212925@fx19.am4> |
| In reply to | #71581 |
On 25/01/2020 22:00, Ian Collins wrote:
> On 26/01/2020 10:33, Bart wrote:
>> How can I respond to that?
>>
>> I've already said I can't tell how much bigger, less readable, less
>> productive it might have been to code like that, how many extra
>> functions etc, compared with just using the odd goto.
>
> The use of RAII generally makes the code smaller (we don't need to
> repeat the deallocation code for each allocation.
>
> As mentioned previously, most uses of goto in C kernel and driver code
> is what amounts to finally clauses, freeing stuff that may have been
> allocated before some error condition is detected. A classic example is
> this short function from the Linux kernel source:
>
> void vga_put(struct pci_dev *pdev, unsigned int rsrc)
> {
> struct vga_device *vgadev;
> unsigned long flags;
>
> /* The one who calls us should check for this, but lets be sure... */
> if (pdev == NULL)
> pdev = vga_default_device();
> if (pdev == NULL)
> return;
> spin_lock_irqsave(&vga_lock, flags);
> vgadev = vgadev_find(pdev);
> if (vgadev == NULL)
> goto bail;
> __vga_put(vgadev, rsrc);
> bail:
> spin_unlock_irqrestore(&vga_lock, flags);
> }
>
> (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/vga/vgaarb.c)
>
> In C++, the lock would be managed so there's no need for a manual unlock
> and therefore no need for the "finally" block.
OK, but that's not a convincing example for that feature, as the goto
can be trivially eliminated just by reversing the condition:
if (vgadev != NULL)
__vga_put(vgadev, rsrc);
spin_unlock_irqrestore(&vga_lock, flags);
(I wonder if some of this was machine translated? Either that or it was
at some point more elabarate but the goto was left in. Or possibly, it
was converted from ASM where you would see that pattern of jump.)
> In C++, the lock would be managed so there's no need for a manual unlock
> and therefore no need for the "finally" block.
And also, regarding the 'lock' business, I don't know enough about
what's going on here to know whether C++ style resource management
(based on some identifiers going out of scope?) would be suitable here.
Does 'vga_lock' even have local scope here? If global, how does C++ know
when to do the unlock?
In this case I'd have more confidence in the explicit C code.
[toc] | [prev] | [next] | [standalone]
| From | Ian Collins <ian-news@hotmail.com> |
|---|---|
| Date | 2020-01-26 11:46 +1300 |
| Message-ID | <h93upcF25s3U11@mid.individual.net> |
| In reply to | #71583 |
On 26/01/2020 11:23, Bart wrote:
> On 25/01/2020 22:00, Ian Collins wrote:
>> On 26/01/2020 10:33, Bart wrote:
>
>>> How can I respond to that?
>>>
>>> I've already said I can't tell how much bigger, less readable, less
>>> productive it might have been to code like that, how many extra
>>> functions etc, compared with just using the odd goto.
>>
>> The use of RAII generally makes the code smaller (we don't need to
>> repeat the deallocation code for each allocation.
>>
>> As mentioned previously, most uses of goto in C kernel and driver code
>> is what amounts to finally clauses, freeing stuff that may have been
>> allocated before some error condition is detected. A classic example is
>> this short function from the Linux kernel source:
>>
>> void vga_put(struct pci_dev *pdev, unsigned int rsrc)
>> {
>> struct vga_device *vgadev;
>> unsigned long flags;
>>
>> /* The one who calls us should check for this, but lets be sure... */
>> if (pdev == NULL)
>> pdev = vga_default_device();
>> if (pdev == NULL)
>> return;
>> spin_lock_irqsave(&vga_lock, flags);
>> vgadev = vgadev_find(pdev);
>> if (vgadev == NULL)
>> goto bail;
>> __vga_put(vgadev, rsrc);
>> bail:
>> spin_unlock_irqrestore(&vga_lock, flags);
>> }
>>
>> (https://elixir.bootlin.com/linux/latest/source/drivers/gpu/vga/vgaarb.c)
>>
>> In C++, the lock would be managed so there's no need for a manual unlock
>> and therefore no need for the "finally" block.
>
> OK, but that's not a convincing example for that feature, as the goto
> can be trivially eliminated just by reversing the condition:
>
> if (vgadev != NULL)
> __vga_put(vgadev, rsrc);
> spin_unlock_irqrestore(&vga_lock, flags);
It wasn't intended to be convincing, it just happened to be a short
function with a "finally" block. There are other examples in that file
with other resource releasing after the label.
> (I wonder if some of this was machine translated? Either that or it was
> at some point more elabarate but the goto was left in. Or possibly, it
> was converted from ASM where you would see that pattern of jump.)
It's a very common idiom in C driver code.
> > In C++, the lock would be managed so there's no need for a manual unlock
> > and therefore no need for the "finally" block.
>
> And also, regarding the 'lock' business, I don't know enough about
> what's going on here to know whether C++ style resource management
> (based on some identifiers going out of scope?) would be suitable here.
>
> Does 'vga_lock' even have local scope here? If global, how does C++ know
> when to do the unlock?
Well it's unlocked immediately before the closing brace which is where
an RAII object would be destroyed.
> In this case I'd have more confidence in the explicit C code.
Until someone introduces an alternative return point and forgets to do
the unlock...
--
Ian.
[toc] | [prev] | [next] | [standalone]
Page 8 of 11 — ← Prev page 1 … 6 7 [8] 9 10 11 Next page →
Back to top | Article view | comp.lang.c++
csiph-web