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 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 13:25 +0100 |
| Message-ID | <rrcubc$onr$1@dont-email.me> |
| In reply to | #157294 |
> C++ model and RAII is a kind of simplification because if > you associate the cleanup function with the type this cannot > be override by instance basis. That's not necessary because the cleanup does what the class is intended for. And if you have a type of object that isn't covered by a pre-defined class and it doesn't make sense to defined a class on your own because you need this type of object too rarely, there are scope-locks which take a lambda-type and a lambda-object which does the cleanup. That's all much more convenient than this rudi- mentary defer-cleanup in C. > With defer, having to inform the cleanup function all the time for > the same type can be repetitive but is something more generic and > and can be used in types that are not classes like FILE. It's more effort than in C++ and it's less readable.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 06:26 -0800 |
| Message-ID | <86bec153-f2b4-4c61-8fe4-0483e0f1e3a4n@googlegroups.com> |
| In reply to | #157298 |
On Wednesday, December 16, 2020 at 9:25:33 AM UTC-3, Bonita Montero wrote: > > C++ model and RAII is a kind of simplification because if > > you associate the cleanup function with the type this cannot > > be override by instance basis. > That's not necessary because the cleanup does what the class is > intended for. And if you have a type of object that isn't covered > by a pre-defined class and it doesn't make sense to defined a class > on your own because you need this type of object too rarely, there > are scope-locks which take a lambda-type and a lambda-object which > does the cleanup. That's all much more convenient than this rudi- > mentary defer-cleanup in C. When we have a type we don't necessarily have a fixed allocation strategy associated with it. The allocator plays a very important role and the destructor is more associated with the allocator than the type. struct Person* p = MyAllocator_Alloc(sizeof * p); ... MyAllocator_Free(p); C++ have several defaults and many mechanisms to customize this, like parametrized allocators, operator new/delete, namespace pmr, and this increase the language size and complexity. defer is a way (alternative) to avoid all the customizations of operator new/delete and the parametrization of allocators.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 15:40 +0100 |
| Message-ID | <rrd68d$h06$1@dont-email.me> |
| In reply to | #157301 |
> When we have a type we don't necessarily have a fixed allocation > strategy associated with it. You can use your own allocator-type with the C++-containers and smart-pointers.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 07:05 -0800 |
| Message-ID | <cf2e92d8-e27f-4c84-a4c7-15ce5a37d8d5n@googlegroups.com> |
| In reply to | #157302 |
On Wednesday, December 16, 2020 at 11:40:31 AM UTC-3, Bonita Montero wrote: > > When we have a type we don't necessarily have a fixed allocation > > strategy associated with it. > You can use your own allocator-type with the C++-containers and > smart-pointers. Yes, I know. In my view, ideally, types should not be associated with allocators because the same type can be used with different strategies. This association type + allocator is required by C++ destructor. On the other hand, using gcc clean_up we have to inform for each instance what is the destroy function. So we can have different strategies for the same type just changing the destroy function. But gcc clean_up does not have capture. We can have a different function but we cannot pass a local allocator for instance. Some instances like FILE have the allocation strategy FIXED, in this case fopen/fclose. We cannot invent a new fopen or fclose so the destructor of FILE could be fixed and associated with the type FILE. The same for mutex. In this case the association type+destructor makes sense.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 16:13 +0100 |
| Message-ID | <rrd86n$vp1$1@dont-email.me> |
| In reply to | #157303 |
> In my view, ideally, types should not be associated with allocators > because the same type can be used with different strategies. Then use a scope-guard.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 16:21 +0100 |
| Message-ID | <rrd8lr$45j$1@dont-email.me> |
| In reply to | #157304 |
> Then use a scope-guard.
That's my scope-guard before C++20:
#pragma once
#include <cassert>
#include "debug_exceptions.h"
template<typename T>
struct invoke_on_destruct
{
private:
T &m_t;
bool m_enabled;
public:
invoke_on_destruct( T &t ) :
m_t( t ), m_enabled( true )
{
}
~invoke_on_destruct()
{
if( m_enabled )
{
try_debug
{
m_t();
}
catch_debug
{
assert(false);
}
}
}
void invoke_and_disable()
{
m_enabled = false;
m_t();
}
void disable()
{
m_enabled = false;
}
};
The cool thing here is that you can use it for transaction-like
operations also, i.e. for operations which should rollback if a
series of operations fail at a certain point; the destructor
would do the rollback-operation but at the end of the whols
operation you simply call disable() and the rollback doesn't
happen:
auto rollback = []()
{
....
};
invoke_on_destruct<decltype(rollback)> iodRollback( rollback );
...
iodRollback.disable();
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-16 17:06 +0100 |
| Message-ID | <rrdbah$n1e$2@dont-email.me> |
| In reply to | #157294 |
On 16/12/2020 12:45, Thiago Adams wrote: > On Wednesday, December 16, 2020 at 7:01:48 AM UTC-3, Bonita Montero wrote: >>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ >> >> Better use C++, it has RAII which does what you try >> to initiate by this deferring manually. > > C++ model and RAII is a kind of simplification because if you > associate the cleanup function with the type this cannot > be override by instance basis. Of course it can - you just make an appropriate class or template. These are often called "scope guard" classes in C++. > > With defer, having to inform the cleanup function all the time for the > same type can be repetitive but is something more generic and > and can be used in types that are not classes like FILE. >
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 08:57 -0800 |
| Message-ID | <a3f26a75-ecbe-4161-917b-d1bee6c190den@googlegroups.com> |
| In reply to | #157310 |
On Wednesday, December 16, 2020 at 1:06:56 PM UTC-3, David Brown wrote: > On 16/12/2020 12:45, Thiago Adams wrote: > > On Wednesday, December 16, 2020 at 7:01:48 AM UTC-3, Bonita Montero wrote: > >>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ > >> > >> Better use C++, it has RAII which does what you try > >> to initiate by this deferring manually. > > > > C++ model and RAII is a kind of simplification because if you > > associate the cleanup function with the type this cannot > > be override by instance basis. > Of course it can - you just make an appropriate class or template. > These are often called "scope guard" classes in C++. > > > > With defer, having to inform the cleanup function all the time for the > > same type can be repetitive but is something more generic and > > and can be used in types that are not classes like FILE. > > Scope guard is just another way to create defer. Right?
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-16 19:43 +0100 |
| Message-ID | <rrdkhc$3qp$1@dont-email.me> |
| In reply to | #157313 |
On 16/12/2020 17:57, Thiago Adams wrote: > On Wednesday, December 16, 2020 at 1:06:56 PM UTC-3, David Brown wrote: >> On 16/12/2020 12:45, Thiago Adams wrote: >>> On Wednesday, December 16, 2020 at 7:01:48 AM UTC-3, Bonita Montero wrote: >>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/ >>>> >>>> Better use C++, it has RAII which does what you try >>>> to initiate by this deferring manually. >>> >>> C++ model and RAII is a kind of simplification because if you >>> associate the cleanup function with the type this cannot >>> be override by instance basis. >> Of course it can - you just make an appropriate class or template. >> These are often called "scope guard" classes in C++. >>> >>> With defer, having to inform the cleanup function all the time for the >>> same type can be repetitive but is something more generic and >>> and can be used in types that are not classes like FILE. >>> > > Scope guard is just another way to create defer. Right? > Yes. I haven't read the proposal in enough detail - there may be minor differences. But they are used for the same purpose. Scopeguard classes work using standard C++, RAII and destructors. (I am not suggesting that switching to C++ is the answer to all C questions, as Bonita seems to think. Nor am I passing any judgement on which might be the neatest or most flexible solution. I'm just saying that anything you can do with a "defer" solution, you can also do with scopeguards using existing C++.)
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-16 12:05 +0000 |
| Message-ID | <FKmCH.1089493$ckra.597974@fx37.ams4> |
| In reply to | #157279 |
On 15/12/2020 21:57, Thiago Adams wrote:
> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
>
This the example used:
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
// use p, q, and mut until the end of the block
...
}
The embedded link leads to a flow diagram which makes it very clear how
it works.
This is fine provided the block is a simple, linear sequence of
statements. It becomes much less clear when parts of it are nested deep
inside conditionals or in loops, or there are gotos in or out of blocks,
or from one part to another.
Or, between 'if (!p) break;' and 'defer free(p)', what happens if there
is another resource declared, with its own break, before the defer
statement for the p resource?
Real code might also use more elaborate clean-up, and the question has
already been raised about the values of the variables involved by the
time the cleanup happens.
My view is that a feature with the number of restrictions and caveats
that would be needed is unsuitable to be added to the core language.
(I think I would also combine the 'if (!p) break;' and 'defer free(p);'
parts into a single indivisible feature, but I haven't looked at it in
depth.)
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-16 14:26 +0100 |
| Message-ID | <rrd1ue$i7q$1@dont-email.me> |
| In reply to | #157296 |
> 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
> // use p, q, and mut until the end of the block
> ...
> }
In C++:
vector<char> p( 25 ),
q( 25 );
lock_guard<mutex> lock( mut );
[toc] | [prev] | [next] | [standalone]
| From | Ben Bacarisse <ben.usenet@bsb.me.uk> |
|---|---|
| Date | 2020-12-16 15:57 +0000 |
| Message-ID | <87mtyd3fr8.fsf@bsb.me.uk> |
| In reply to | #157296 |
Bart <bc@freeuk.com> writes:
> On 15/12/2020 21:57, Thiago Adams wrote:
>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
>
> This the example used:
>
> 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
> // use p, q, and mut until the end of the block
> ...
> }
(Just piggybacking because you posted the example.)
I boring old C, I'd write
void *const p = malloc(25), *const q = malloc(25);
if (mtx_lock(&mut) == thrd_success) {
// use resources...
mtx_unlock(&mut);
}
free(p);
free(q);
and if the second malloc really must be conditional
void *const p = malloc(25), *const q = p ? malloc(25) : 0;
The main cited advantage is the proximity of the defer to the
allocation, but the result is inelegant in my option. I keep thinking
there must be better, more compelling examples.
--
Ben.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2020-12-16 19:49 +0100 |
| Message-ID | <rrdkrk$6eq$1@dont-email.me> |
| In reply to | #157307 |
On 16/12/2020 16:57, Ben Bacarisse wrote:
> Bart <bc@freeuk.com> writes:
>
>> On 15/12/2020 21:57, Thiago Adams wrote:
>>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
>>
>> This the example used:
>>
>> 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
>> // use p, q, and mut until the end of the block
>> ...
>> }
>
> (Just piggybacking because you posted the example.)
>
> I boring old C, I'd write
>
> void *const p = malloc(25), *const q = malloc(25);
> if (mtx_lock(&mut) == thrd_success) {
> // use resources...
> mtx_unlock(&mut);
> }
> free(p);
> free(q);
>
> and if the second malloc really must be conditional
>
> void *const p = malloc(25), *const q = p ? malloc(25) : 0;
>
and then you'd want :
if (q && (mtx_lock(&mut) == thrd_success)) {
> The main cited advantage is the proximity of the defer to the
> allocation, but the result is inelegant in my option. I keep thinking
> there must be better, more compelling examples.
>
Basically, it let's you write code in the form:
void * const p = malloc(25);
if (!p) return;
void * const q = malloc(25);
if (!q) return;
Sometimes it's nicer to write in that way, especially if there are
different things that can fail at different times, and if you want to
report the status back to the calling function.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 11:33 -0800 |
| Message-ID | <ac49d11c-67fa-4a17-bb31-a4c6db07af89n@googlegroups.com> |
| In reply to | #157317 |
On Wednesday, December 16, 2020 at 3:49:41 PM UTC-3, David Brown wrote:
> On 16/12/2020 16:57, Ben Bacarisse wrote:
> > Bart <b...@freeuk.com> writes:
> >
> >> On 15/12/2020 21:57, Thiago Adams wrote:
> >>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
> >>
> >> This the example used:
> >>
> >> 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
> >> // use p, q, and mut until the end of the block
> >> ...
> >> }
> >
> > (Just piggybacking because you posted the example.)
> >
> > I boring old C, I'd write
> >
> > void *const p = malloc(25), *const q = malloc(25);
> > if (mtx_lock(&mut) == thrd_success) {
> > // use resources...
> > mtx_unlock(&mut);
> > }
> > free(p);
> > free(q);
> >
> > and if the second malloc really must be conditional
> >
> > void *const p = malloc(25), *const q = p ? malloc(25) : 0;
> >
> and then you'd want :
>
> if (q && (mtx_lock(&mut) == thrd_success)) {
> > The main cited advantage is the proximity of the defer to the
> > allocation, but the result is inelegant in my option. I keep thinking
> > there must be better, more compelling examples.
> >
> Basically, it let's you write code in the form:
> void * const p = malloc(25);
> if (!p) return;
> void * const q = malloc(25);
> if (!q) return;
>
> Sometimes it's nicer to write in that way, especially if there are
> different things that can fail at different times, and if you want to
> report the status back to the calling function.
I have suggested here some time ago a IF + initializer + defer.
Here is a macro:
#define __if(init, condition, defer) for(init, *ptemp=(void*)1; ptemp && (condition) ; (defer), ptemp=0)
int main()
{
__if(void* const p = malloc(25), p, free(p)) {
__if(void* const q = malloc(25), q, free(q)) {
__if(int e = mtx_lock(&mut), e != thrd_error, mtx_unlock(&mut)) {
// use resources...
}
}
}
}
I also have implemented this feature in my transpiler
http://thradams.com/web2/cprime.html
Select the sample "if with initializer and defer"
I haven't implemented break, continue, return or goto inside...
For break, continue or return the compiler could just call
all "defers" that are in the scope before call break or return or continue.
The generated for:
if(void* const p = malloc(25); p; free(p)) {
if(void* const q = malloc(25); q; free(q)) {
}
}
is:
{void* const p = malloc(25);if( p){
{
{void* const q = malloc(25);if( q){
{
} free(q);}}
} free(p);}}
This is always static and without capture. The expression is evaluated
at the end and before break continue etc.
Let's say we have break inside
for (;;)
{
if(void* const p = malloc(25); p; free(p)) {
if(void* const q = malloc(25); q; free(q)) {
break;
}
}
}
In this case the generated code would be:
{void* const p = malloc(25);if( p){
{
{void* const q = malloc(25);if( q){
{
free(q); free(p); break;
} free(q);}}
} free(p);}}
(For my transpiler I also need to take care about duplicated names,
I need to rename the variables for unique names)
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-16 13:05 -0800 |
| Message-ID | <8e727021-225c-48f5-a61a-6cfca3f1074dn@googlegroups.com> |
| In reply to | #157318 |
On Wednesday, December 16, 2020 at 4:33:36 PM UTC-3, Thiago Adams wrote: ... http://thradams.com/web2/cprime.html I did one update and now I am handling break continue and return inside if defer block.
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-17 01:52 +0300 |
| Message-ID | <20201217015210.bb1e73129bd89307422c8adf@gmail.com> |
| In reply to | #157318 |
Thiago Adams:
> The generated for:
>
> if(void* const p = malloc(25); p; free(p)) {
> if(void* const q = malloc(25); q; free(q))
> {
>
> }
> }
>
> is:
>
> {void* const p = malloc(25);if( p){
> {
> {void* const q = malloc(25);if( q){
> {
>
> } free(q);}}
> } free(p);}}
>
I do not think it much of an improvement because you still
have to write nested code, while it is essentially linear.
It becomes rather annoying after three levels of nesting:
if(void* const p = malloc(25); p; free(p)) {
if(void* const q = malloc(25); q; free(q)) {
if(void* const r = malloc(25); r; free(r)) {
if(void* const s = malloc(25); s; free(s)) {
}
}
}
}
I want to express an essentially linear algorithm in linear
code, e.g.:
runlevel = 0;
p = malloc(25); if( p == NULL ) goto End;
runlevel += 1;
q = malloc(25); if( q == NULL ) goto End;
runlevel += 1;
r = malloc(25); if( r == NULL ) goto End;
runlevel += 1;
/* do things */
End:
switch( runlevel ) /* fallthough! */
{ case 3: free( r );
case 2: free( q );
case 1: free( p ); break;
}
On the other hand, sometimes you can thus collapse your
code:
if(void* const p = malloc(25); p; free(p))
if(void* const q = malloc(25); q; free(q))
if(void* const r = malloc(25); r; free(r))
if(void* const s = malloc(25); s; free(s))
{ /* do things */ }
and then it starts to look like stacked `using' statements
in C#:
using( a = GiveMeA( ) )
using( b = GiveMeB( a ) )
using( c = GiveMeC( a, b ) )
{ /* do things */ }
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-17 10:59 -0800 |
| Message-ID | <89888024-715a-4493-b3e1-dd6026932e6fn@googlegroups.com> |
| In reply to | #157333 |
On Wednesday, December 16, 2020 at 7:52:24 PM UTC-3, Anton Shepelev wrote:
...
> On the other hand, sometimes you can thus collapse your
> code:
> if(void* const p = malloc(25); p; free(p))
> if(void* const q = malloc(25); q; free(q))
> if(void* const r = malloc(25); r; free(r))
> if(void* const s = malloc(25); s; free(s))
> { /* do things */ }
I select a real world code to rewrite and see if I like the result.
// Returns an allocated string with all the content of the file or null.
char* readfile(const char* path);
char* readfile(const char* path) {
char* result = NULL;
if (struct stat info; stat(path, &info) == 0)
if (char* data = malloc(sizeof(char) * info.st_size + 1); data; free(data))
if (FILE* file = fopen(path, "r"); file; fclose(file))
{
size_t n = fread(data, 1, info.st_size, file);
data[n] = 0;
result = data;
data = 0;
}
return result;
}
int main() {
if (char* s = readfile("hello.c"); s; free(s)) {
}
}
Original code:
char* readfile(const char* path)
{
char* data = 0;
struct stat info;
int r = stat(path, &info);
if (r == 0) {
data = (char*)malloc(sizeof(char) * info.st_size + 1);
if (data != NULL) {
FILE* file = fopen(path, "r");
if (file != NULL) {
size_t n = fread(data, 1, info.st_size, file);
data[n] = 0;
fclose(file);
return data;
}
else
{
free(data);
data = 0;
}
}
}
return data;
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 20:47 +0100 |
| Message-ID | <rrgck7$s3d$1@dont-email.me> |
| In reply to | #157345 |
> char* readfile(const char* path) {
> char* result = NULL;
>
> if (struct stat info; stat(path, &info) == 0)
> if (char* data = malloc(sizeof(char) * info.st_size + 1); data; free(data))
> if (FILE* file = fopen(path, "r"); file; fclose(file))
> {
> size_t n = fread(data, 1, info.st_size, file);
> data[n] = 0;
> result = data;
> data = 0;
> }
>
> return result;
> }
>
> int main() {
> if (char* s = readfile("hello.c"); s; free(s)) {
> }
> }
>
> Original code:
>
> char* readfile(const char* path)
> {
> char* data = 0;
> struct stat info;
> int r = stat(path, &info);
> if (r == 0) {
> data = (char*)malloc(sizeof(char) * info.st_size + 1);
> if (data != NULL) {
> FILE* file = fopen(path, "r");
> if (file != NULL) {
> size_t n = fread(data, 1, info.st_size, file);
> data[n] = 0;
> fclose(file);
> return data;
> }
> else
> {
> free(data);
> data = 0;
> }
> }
> }
> return data;
> }
When I look at this rudimentary code I think its frustrating to program
in C today when you have better opportunities like C++. In the 90s when
I learned C when I was about 14 I was quite happy because I could easily
imagine the connection between the code I wrote and the generated assem-
bly-code. But when I learned C++ I learned to appreciate the comfort of
a classlib like the STL, RAII, exceptions and OOP so that I became too
lazy to do all the details manually in C.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-17 19:58 +0000 |
| Message-ID | <20201217115335.159@kylheku.com> |
| In reply to | #157352 |
On 2020-12-17, Bonita Montero <Bonita.Montero@gmail.com> wrote: > in C today when you have better opportunities like C++. In the 90s when > I learned C when I was about 14 I was quite happy because I could easily In the 90s I was employed as a C++ developer. Yet, somehow I don't rabidly advocate this language in the C newsgroup. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 21:56 +0100 |
| Message-ID | <rrggme$oat$2@dont-email.me> |
| In reply to | #157353 |
> In the 90s I was employed as a C++ developer. ... Until C++98 C++ wasn't a mature language and the compiler's interpretation of the standard was very different among the compilers for a even longer time. With C++11 the language has made it's largest leap it has ever made. Stroustrup said that the language became like a new language with C++11 and he was right.
[toc] | [prev] | [next] | [standalone]
Page 7 of 15 — ← Prev page 1 … 5 6 [7] 8 9 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web