Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #157279 > unrolled thread
| Started by | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| First post | 2020-12-15 13:57 -0800 |
| Last post | 2020-12-21 22:17 +0100 |
| Articles | 20 on this page of 300 — 18 participants |
Back to article view | Back to comp.lang.c
A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-15 13:57 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-16 02:11 +0300
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 01:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 10:48 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 04:16 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:04 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 16:06 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 15:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 19:32 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-17 21:12 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-17 13:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:35 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 06:05 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 15:28 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 08:49 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 18:24 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 10:31 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 16:53 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:33 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:06 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-18 11:55 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:09 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-18 15:39 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 21:55 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 17:05 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 17:12 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:41 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 10:13 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:28 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 11:35 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:45 +0100
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-19 13:26 -0500
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 11:31 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 20:41 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 19:57 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:05 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 20:26 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:59 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 15:23 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 17:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:21 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 20:13 +0000
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 17:37 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 16:26 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-25 00:55 +0000
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 12:10 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 13:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 14:01 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 16:32 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 07:42 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-20 16:07 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:38 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 17:25 +0100
Re: A defer mechanism for C Christian Hanné <the.hanne@gmail.com> - 2020-12-20 17:46 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 09:07 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:43 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-20 10:11 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 14:58 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:58 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 18:41 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 18:45 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-20 20:25 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 22:34 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 20:52 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-20 12:37 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 08:42 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:19 -0500
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-21 10:18 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 11:06 -0500
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:09 -0500
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:13 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 13:18 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:26 -0700
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:47 -0500
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-24 00:59 -0500
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:25 -0700
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-21 14:23 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-22 09:58 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:57 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 04:19 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-27 11:24 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-28 22:45 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 00:33 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 11:31 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-29 17:24 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-29 18:43 +0100
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-29 11:32 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 03:34 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-29 21:06 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-29 20:40 -0800
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-31 02:56 -0800
Re: A defer mechanism for C Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2020-12-23 17:22 -0700
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 02:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 06:49 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-24 03:16 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-24 13:38 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:37 -0800
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-25 11:39 -0500
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:34 -0800
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-26 22:48 -0800
Re: A defer mechanism for C Richard Damon <Richard@Damon-Family.org> - 2020-12-27 08:51 -0500
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-24 22:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 09:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:18 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 09:32 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-19 18:55 +0100
Re: A defer mechanism for C "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2020-12-24 14:16 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-17 22:05 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-18 11:42 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 05:53 -0800
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:40 +0000
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-27 05:19 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 11:01 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 03:45 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 13:25 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 06:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 15:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 07:05 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:13 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 16:21 +0100
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 17:06 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 08:57 -0800
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:43 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-16 12:05 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 14:26 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 15:57 +0000
Re: A defer mechanism for C David Brown <david.brown@hesbynett.no> - 2020-12-16 19:49 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 11:33 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:05 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:52 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 10:59 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 20:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 19:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 21:56 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:03 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 12:30 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:16 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:39 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-17 13:44 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 06:54 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 13:28 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:14 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:16 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:19 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:26 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 17:07 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 18:18 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 18:34 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:40 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 21:16 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 22:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 21:50 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:25 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:01 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:47 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 02:45 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:48 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 13:33 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:24 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:28 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-24 21:55 -0800
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:26 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:38 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:51 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-25 20:00 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:19 +0100
Re: A defer mechanism for C Öö Tiib <ootiib@hot.ee> - 2020-12-26 19:10 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-27 05:28 +0100
Re: A defer mechanism for C Michael S <already5chosen@yahoo.com> - 2020-12-25 05:42 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-25 14:52 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 02:29 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 12:11 +0100
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-26 09:33 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-26 18:50 +0100
Re: A defer mechanism for C Tim Rentsch <tr.17687@z991.linuxsc.com> - 2020-12-26 07:40 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:36 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 17:49 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:39 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-18 16:25 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 01:55 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 23:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:16 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:33 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:55 +0100
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-18 19:10 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 16:47 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 15:22 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:09 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 07:25 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 08:02 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 22:55 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 21:58 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 23:05 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:40 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:59 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:10 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-17 22:46 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:46 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-18 01:00 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 10:59 -0800
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 11:12 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:18 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-18 16:25 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 19:24 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 09:07 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:36 +0300
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-19 15:54 -0500
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-20 01:21 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-20 15:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:53 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 11:55 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 12:07 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 03:38 -0800
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 01:40 +0000
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:00 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:02 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:22 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:43 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 12:34 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 17:11 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-19 17:22 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:08 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 15:26 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 04:36 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:54 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 22:12 +0300
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 15:13 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 12:45 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 16:25 +0300
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 13:38 +0000
Re: A defer mechanism for C James Kuyper <jameskuyper@alumni.caltech.edu> - 2020-12-21 09:26 -0500
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 20:30 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-16 21:41 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:14 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 19:25 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-18 18:38 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-18 20:44 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 02:07 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 00:51 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 16:51 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-19 06:15 -0800
Re: A defer mechanism for C Malcolm McLean <malcolm.arthur.mclean@gmail.com> - 2020-12-19 06:25 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:58 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-19 18:43 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 16:56 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:55 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 15:52 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 00:40 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 11:46 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 20:22 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-19 21:31 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-19 22:27 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-20 09:36 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-21 21:02 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:24 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-16 13:07 -0800
Re: A defer mechanism for C Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2020-12-16 18:35 -0800
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-17 04:08 +0000
Re: A defer mechanism for C Ben Bacarisse <ben.usenet@bsb.me.uk> - 2020-12-16 23:13 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-17 07:24 +0100
Re: A defer mechanism for C Kaz Kylheku <563-365-8930@kylheku.com> - 2020-12-16 20:29 +0000
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-17 01:26 +0300
Re: A defer mechanism for C fir <profesor.fir@gmail.com> - 2020-12-21 05:02 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 15:03 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 06:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 16:51 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:17 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:22 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:36 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:40 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:46 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:04 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 10:57 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:10 +0100
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 11:39 -0800
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 20:48 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:08 +0100
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 21:34 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:15 +0300
Re: A defer mechanism for C Thiago Adams <thiago.adams@gmail.com> - 2020-12-21 08:26 -0800
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 19:45 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 17:31 +0100
Re: A defer mechanism for C Anton Shepelev <anton.txt@gmail.com> - 2020-12-21 20:15 +0300
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 18:28 +0100
Re: A defer mechanism for C Bart <bc@freeuk.com> - 2020-12-21 20:49 +0000
Re: A defer mechanism for C Bonita Montero <Bonita.Montero@gmail.com> - 2020-12-21 22:17 +0100
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 15:52 +0100 |
| Message-ID | <rrl42s$1g1$1@dont-email.me> |
| In reply to | #157454 |
> That is a good example, but since I am not disposed to agree > with you easily, I will need I profiler trace that > demonstrates that the C overhead is significant. If it is 5% > I won't care and call exceptions not worth it. Remember that these checks are needed at each call-level up to the function that finally receives a error-code. In C++ the error-condition is detected in the allocation-routine and will be processed only in the outermost scope.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-19 00:40 +0000 |
| Message-ID | <20201218163506.344@kylheku.com> |
| In reply to | #157416 |
On 2020-12-18, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> The C++ assembly output is by far larger for sure becuase modern > >> Larger than what? I have not shown any assembly output that is larger >> than some other assembly output. I showed two snippets of assembly >> output which show that two functions are identical. > > I have explained why automatic error-handling through exceptions > results in a larger executable-size than in C and why the perfor- > mance is higher. > >> The C style routine, which has no destructors in it and therefore >> does not have to be referenced by any exception handling tables, >> translates to exactly the same machine code as the function that >> calls constructors and destructors. > > But error-handling in C is slower because of what I've explained. You have no proof of your claim which approaches the quality of how I just showed that RAII, in the context of regular programmatic error handling, has exactly the same cost as C style code. I didn't expect bit-exact machine code, but that was a nice bonus. A program which bubbles up return codes is significantly different from one which uses exceptions. Another consideration to make things more complicated is that in C we have setjmp/longjmp which can be used on their own for simple error recovery, or wrapped into a formidable exception handling system. "Error-handling in C" encompasses that body of techniques.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 11:46 +0100 |
| Message-ID | <rrklm3$1oe$1@dont-email.me> |
| In reply to | #157434 |
>> But error-handling in C is slower because of what I've explained. > You have no proof of your claim which approaches the quality of how I > just showed that RAII, in the context of regular programmatic error > handling, has exactly the same cost as C style code. I didn't expect > bit-exact machine code, but that was a nice bonus. Google for table-driven exception-handling. It is well known that table-driven exception-handling has almost no overhead at the cost of space for the tables and additional unwind-code for if a exception is thrown.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-19 20:22 +0000 |
| Message-ID | <20201219121808.598@kylheku.com> |
| In reply to | #157440 |
On 2020-12-19, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> But error-handling in C is slower because of what I've explained. > >> You have no proof of your claim which approaches the quality of how I >> just showed that RAII, in the context of regular programmatic error >> handling, has exactly the same cost as C style code. I didn't expect >> bit-exact machine code, but that was a nice bonus. > > Google for table-driven exception-handling. It is well known > that table-driven exception-handling has almost no overhead > at the cost of space for the tables and additional unwind-code > for if a exception is thrown. That much was obvious from the disassembly listings I posted, which showed identical code for code using RAII destructors, versus C like code without constructor/destructor calls. The hard-to-profe position you posited is that throwing and handling the C++ exception is faster than approaches that are available in C. I don't understand why you're changing the topic. Well, actually I understand it, but you must think that everyone is an idiot who won't notice. Wait, it's obvious you think everyone is an idiot, also.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 21:31 +0100 |
| Message-ID | <rrlnul$i1l$1@dont-email.me> |
| In reply to | #157494 |
> That much was obvious from the disassembly listings I posted, which > showed identical code for code using RAII destructors, versus C like > code without constructor/destructor calls. Then you didn't show everything. The unroll-handlers and tables for thrown exceptions make the code very differend. > The hard-to-profe position you posited is that throwing and handling > the C++ exception is faster than approaches that are available in C. Of course it is faster since there aren't any return-code checks in C++.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-19 22:27 +0000 |
| Message-ID | <20201219142409.419@kylheku.com> |
| In reply to | #157497 |
On 2020-12-19, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> That much was obvious from the disassembly listings I posted, which >> showed identical code for code using RAII destructors, versus C like >> code without constructor/destructor calls. > > Then you didn't show everything. The unroll-handlers and tables > for thrown exceptions make the code very differend. > >> The hard-to-profe position you posited is that throwing and handling >> the C++ exception is faster than approaches that are available in C. > > Of course it is faster since there aren't any return-code checks in C++. Of course, fiddlesticks. Firstly, there is an exception search which has to unwind the stack, and access and process the exception tables or whatever representation is used. It has to run the necessary clean-up code. Whether that is faster and in what situations is far from clear. Secondly, you weren't paying attention. Techniques involving non-local exits are available in C. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-20 09:36 +0100 |
| Message-ID | <rrn2e9$qj5$1@dont-email.me> |
| In reply to | #157500 |
>> Of course it is faster since there aren't any return-code checks in C++. > Of course, fiddlesticks. Firstly, there is an exception search which has > to unwind the stack, and access and process the exception tables or > whatever representation is used. It has to run the necessary clean-up > code. Whether that is faster and in what situations is far from clear. I'm talking about the performance-relevant case if no exception is thrown. The performance of throwing exceptions isn't relevant. > Secondly, you weren't paying attention. Techniques involving non-local > exits are available in C. stjmp() / longjmp() - with no cleanups like RAI ? LOL.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-21 21:02 +0000 |
| Message-ID | <20201221123845.478@kylheku.com> |
| In reply to | #157501 |
On 2020-12-20, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Of course it is faster since there aren't any return-code checks in C++. > >> Of course, fiddlesticks. Firstly, there is an exception search which has >> to unwind the stack, and access and process the exception tables or >> whatever representation is used. It has to run the necessary clean-up >> code. Whether that is faster and in what situations is far from clear. > > I'm talking about the performance-relevant case if no exception > is thrown. The performance of throwing exceptions isn't relevant. Ah, OK; basically I agree with that. Checking for a rarely occurring error at multiple levels of block or function call nesting is expensive compared to not having to do that at all due to exceptions taking care of it. (I take it for granted that code that exists and is executed is almost always slower than code that doesn't exist. I say almost, because I'm always prepared to be delighted by reports of highly weird circumstances.) I consider exception handling essential; I am not arguing against it, as such. I consider it so essential that I've almost forgotten the above efficiency advantage. The (1) expressiveness advantage of not cluttering the "happy" execution path of the code with checks and (2) the thoroughness of it (no risk of forgetting a check) overshadow the speed advantage, but that is nice also. I wouldn't start a new C project from scratch without implementing exception handling. (In fact, I developed an exception handling library in the late 1990's which is used in Wireshark for catching truncated or otherwise malformed packets.) A new programming language invented today without exception handling is too stupid for words. (And no, I don't consider option types to be a serious contender against exception handling, because they still require checking at every level. They just deal with the problem of forgotten checks.) Also, in this paragraph, by "today" I actually refer to the last 35 years. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-21 22:24 +0100 |
| Message-ID | <rrr3qm$aen$1@dont-email.me> |
| In reply to | #157618 |
>>> Of course, fiddlesticks. Firstly, there is an exception search which has >>> to unwind the stack, and access and process the exception tables or >>> whatever representation is used. It has to run the necessary clean-up >>> code. Whether that is faster and in what situations is far from clear. >> I'm talking about the performance-relevant case if no exception >> is thrown. The performance of throwing exceptions isn't relevant. > I consider exception handling essential; I am not arguing against it, > as such. The only thing I dislike with C++ exception-handling is that you might miss an exception which is thrown; i.e. you have carefully check each function called for the exceptions it might throw and write down this exceptions in the documentation. Another approach which sometimes fits is to cach all top-level-exception objects in a central place and to don't care for the more specialized exceptions (the exception-objects still can tell you more about the state with .what() for the standard C++-exception). For me the coronation of error-handing is exception -handling like in Java with checked exceptions and concatenating exceptions from a specialized exception-class to more and more common exception-classes as you get further to the head of the exception-chain. > I wouldn't start a new C project from scratch without implementing > exception handling. Doing the same in C is impossible. The Cfront-writers (C++-to-C-trans- piler) failed to implement exceptions in C, so you won't manage that manually.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 13:07 -0800 |
| Message-ID | <75536c1f-7862-4099-bbb8-e050c3a645e4n@googlegroups.com> |
| In reply to | #157321 |
On Wednesday, December 16, 2020 at 5:41:38 PM UTC-3, Bonita Montero wrote:
> > if ((p = malloc(25)) &&
> > (q = malloc(25)) &&
> > mtx_lock(&mut) == thrd_success) {
> Then you would have to set all values before to a zero-state and
> check all values afterwards if theire not zero. With this deferrring
> or RAII in C++ only the initialized values are going to be destructed.
> That's more efficient. And In C++ that's even more convenient as already
> initialized sub-objects are desrtructed when the destructor of the outer
> object can't complete and throws an exception.
One way to initialize objects with zeros in C is calloc.
I am using it much more than malloc.
Generally zeros is the "best constructor" state.
[toc] | [prev] | [next] | [standalone]
| From | Keith Thompson <Keith.S.Thompson+u@gmail.com> |
|---|---|
| Date | 2020-12-16 18:35 -0800 |
| Message-ID | <87czz9cg7n.fsf@nosuchdomain.example.com> |
| In reply to | #157324 |
Thiago Adams <thiago.adams@gmail.com> writes:
> On Wednesday, December 16, 2020 at 5:41:38 PM UTC-3, Bonita Montero wrote:
>> > if ((p = malloc(25)) &&
>> > (q = malloc(25)) &&
>> > mtx_lock(&mut) == thrd_success) {
>> Then you would have to set all values before to a zero-state and
>> check all values afterwards if theire not zero. With this deferrring
>> or RAII in C++ only the initialized values are going to be destructed.
>> That's more efficient. And In C++ that's even more convenient as already
>> initialized sub-objects are desrtructed when the destructor of the outer
>> object can't complete and throws an exception.
>
> One way to initialize objects with zeros in C is calloc.
> I am using it much more than malloc.
> Generally zeros is the "best constructor" state.
Keep in mind that the language doesn't guarantee that this will
set pointers to NULL or floating-point objects to 0.0.
Your implementation might, and if you want to rely on that that's
fine. I merely advocate awareness.
--
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 | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-17 04:08 +0000 |
| Message-ID | <20201216200145.487@kylheku.com> |
| In reply to | #157336 |
On 2020-12-17, Keith Thompson <Keith.S.Thompson+u@gmail.com> wrote:
> Thiago Adams <thiago.adams@gmail.com> writes:
>> On Wednesday, December 16, 2020 at 5:41:38 PM UTC-3, Bonita Montero wrote:
>>> > if ((p = malloc(25)) &&
>>> > (q = malloc(25)) &&
>>> > mtx_lock(&mut) == thrd_success) {
>>> Then you would have to set all values before to a zero-state and
>>> check all values afterwards if theire not zero. With this deferrring
>>> or RAII in C++ only the initialized values are going to be destructed.
>>> That's more efficient. And In C++ that's even more convenient as already
>>> initialized sub-objects are desrtructed when the destructor of the outer
>>> object can't complete and throws an exception.
>>
>> One way to initialize objects with zeros in C is calloc.
>> I am using it much more than malloc.
>> Generally zeros is the "best constructor" state.
>
> Keep in mind that the language doesn't guarantee that this will
> set pointers to NULL or floating-point objects to 0.0.
>
> Your implementation might, and if you want to rely on that that's
> fine. I merely advocate awareness.
I've been aware of that for some 25 years now, and it has never resulted
in any concrete value in my work.
An implemenation which doesn't make the guarantee will cause a whole lot
of important C code not to be portable to it. Such an implementation
could never be a supercomputer, server, desktop, mobile or embedded SoC
system. Not a viable one that doesn't die a quick and miserable death in
its respective marketplace.
The world has moved on from 9 bit chars, sign-magnitude integers, weird
bit patterns for null pointers and zero floating-point and so on.
It probably won't be looking back.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-16 23:13 +0000 |
| Message-ID | <87zh2d1h1b.fsf@bsb.me.uk> |
| In reply to | #157321 |
Bonita Montero <Bonita.Montero@gmail.com> writes:
>> if ((p = malloc(25)) &&
>> (q = malloc(25)) &&
>> mtx_lock(&mut) == thrd_success) {
>
> Then you would have to set all values before to a zero-state and
> check all values afterwards if theire not zero.
No. The pointers have to be zeroed (though in this example only q), but
free(p) is well-defined when p is a null pointer so there is not need to
check anywhere but this if. The mutex should not be zeroed, but it is
unlocked only in the block that uses it.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 07:24 +0100 |
| Message-ID | <rretjq$7d9$3@dont-email.me> |
| In reply to | #157335 |
>>> if ((p = malloc(25)) &&
>>> (q = malloc(25)) &&
>>> mtx_lock(&mut) == thrd_success) {
>> Then you would have to set all values before to a zero-state and
>> check all values afterwards if theire not zero.
> No. The pointers have to be zeroed (though in this example only q), but
> free(p) is well-defined when p is a null pointer ...
That's even slower.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-16 20:29 +0000 |
| Message-ID | <20201216120840.274@kylheku.com> |
| In reply to | #157279 |
On 2020-12-15, Thiago Adams <thiago.adams@gmail.com> wrote:
> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
This nosnsense of add cleanup statements as you go is not such a great
idea.
This:
guard {
void * const p = malloc(25);
if (!p) break;
defer free(p);
void * const q = malloc(25);
if (!q) break;
defer free(q);
if (mtx_lock(&mut)==thrd_error) break;
defer mtx_unlock(&mut);
// all resources acquired
}
Should be:
{
void *p = 0, *q = 0;
try {
p = malloc(25);
q = malloc(25);
if (q && p && mtx_lock(&mut) !+ thrd_error) try {
// statements in mutex-protected critical region
} finally {
mtx_unlock(&mut);
}
} finally {
free(q);
free(p);
}
}
What happens if you defer stuff in a loop?
guard {
for (;;) {
void * const p = malloc(25);
if (!p)
break;
defer free(p);
}
}
Does defer keep pushing new items onto a list? Where does the memory
come from for that: alloca? The try/finally mechanism is implementable
without any underlying list structure.
--
TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-17 01:26 +0300 |
| Message-ID | <20201217012623.d4ceeb7a890ed96a471e9b55@gmail.com> |
| In reply to | #157279 |
Thiago Adams: > https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ C is a single-paradigm language that implements the simplest and most intuitive of all programming paradigms -- that of procedural programming, where the code is written in the order of its execution. The proposal introduces a new control-flow statement that violates that principle by acting at a distance and over time. It has no apparent effect at the moment of its execution but is taken into account at the end of the guard block, which makes it the most complicated and unnatural control-flow statement in C. Its main advertised advantage is the colocation of initialisation and deinitialisation code for the same variable, but is it really an advatage for an imperative procedural language with straight-forward sequential execution of code? In my opinion, the chronological order is much better: initialise, use, deinitialise. If you want cohesion, make the definitions of your open() and close() functions adjacent, but please express execution in chronological order. The usual objection that one is not forced to use any new feature of the language unfortunately does not work well in practice, because this new feature quicky becomes the topic of interviews for programing jobs, and whoever opposes it is labelled an incompetent retrograde and falls under the peer pressure of those types that consider every new feature an improvement. I used to have collegues that never delacred proper C# delegates if they could do it with generic templates, i.e.: delegate void OnError( int severity, string message ); Action< int, string > OnError; Others *always* used yield return instead of plain loops over enumarators, and complicated lambda-expressions with undebugguble anonymous methods for accessing collections. The typical justification was that a) it is the modern way, and b) it is more scalable. But the probablity of scaling those overengineered pieces of code was never considered. It is for these, partly personal, reasons that I consider new features dangerous, and such revolutionaly features as deferred execution doubly so. The industry is too eager to abuse them. Using is never enough. They soon appear in mandatory coding guidelines and there you are -- programming in a langage that you would dream of in the worst nightmares when began to study it. Is it not the exact story of C++? -- () ascii ribbon campaign -- against html e-mail /\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | fir <profesor.fir@gmail.com> |
|---|---|
| Date | 2020-12-21 05:02 -0800 |
| Message-ID | <c29550cc-2478-43a4-95b8-79619e5915a6n@googlegroups.com> |
| In reply to | #157279 |
wtorek, 15 grudnia 2020 o 22:57:21 UTC+1 Thiago Adams napisał(a): > https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ (this thread is boring so i will not quite answer on it but more on c back again) what c needs, aside some repairs i was talking along the years (like returning many values, resizable arrays, ad-hoc enums), is changes to make source be shorter some way is to make it naked form work (i mean with removing this overuse of parenthesis commas semicolons and bracers) but also i wonder about some aliases included (?) (in fact maybe something live macros but more guarded and intellignt (like being scope wise atc) ...also maybe some improvements of tis control flow logic are needed (would be helpfull)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-21 15:03 +0100 |
| Message-ID | <rrq9vn$oo$1@dont-email.me> |
| In reply to | #157574 |
> what c needs, aside some repairs i was talking along the years (like returning > many values, resizable arrays, ad-hoc enums), is changes to make source be shorter C will never have the abstraction-facilities that help to prevent boilerplate-code. You always have to write this code in detail and with other languages like Rust and C++ you can have do this casually. The STL-containers are a good example. With using them you can have a line of code which would to lead to hundreds of LOCs in C.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-21 06:36 -0800 |
| Message-ID | <1c12cc49-6040-4605-914a-28ea64ff3b26n@googlegroups.com> |
| In reply to | #157580 |
On Monday, December 21, 2020 at 11:03:52 AM UTC-3, Bonita Montero wrote: > > what c needs, aside some repairs i was talking along the years (like returning > > many values, resizable arrays, ad-hoc enums), is changes to make source be shorter > C will never have the abstraction-facilities that help to prevent > boilerplate-code. The door is open.. but it needs to follow some principles. Which is funny, the more I use C, less I want to change it. We can be very productive with less concepts. I will give you an sample... I took me some time to realize that we don't need (in most cases) constructor in C. There is some problems but we need to compare with the cost of solution. > You always have to write this code in detail and > with other languages like Rust and C++ you can have do this casually. You have to accept all "defaults" or program like C. > The STL-containers are a good example. With using them you can have > a line of code which would to lead to hundreds of LOCs in C. When all I need is a ordinary vector, I miss it in C.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-21 16:51 +0100 |
| Message-ID | <rrqgag$ji9$1@dont-email.me> |
| In reply to | #157583 |
>> The STL-containers are a good example. With using them you can have >> a line of code which would to lead to hundreds of LOCs in C. > When all I need is a ordinary vector, I miss it in C. And a string is also needed very often, and it isn't like a vector but has a string-specific string-traits class which is used to compare strings according to their charset. But the vector is of course the most important class. But there are others which are commonly used like a unordered_map or a ordered map.
[toc] | [prev] | [next] | [standalone]
Page 14 of 15 — ← Prev page 1 … 12 13 [14] 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web