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 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-18 18:03 +0000 |
| Message-ID | <20201218100256.776@kylheku.com> |
| In reply to | #157358 |
On 2020-12-17, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> 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. Your comments about RAII in this thread are not about C++11, though. RAII is an old feature that was pretty much was fully developed in C++98. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-17 12:30 -0800 |
| Message-ID | <db1a5f1c-7ec8-401d-ac39-a1eddd66ca65n@googlegroups.com> |
| In reply to | #157352 |
On Thursday, December 17, 2020 at 4:47:35 PM UTC-3, Bonita Montero wrote:
...
> 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.
This is the code I like: (standard C)
char* readfile(const char* path)
{
char* result = NULL;
struct stat info;
if(stat(path, &info) == 0)
{
char* data = malloc(sizeof(char) * info.st_size + 1);
if (data)
{
FILE* file = fopen(path, "r");
if (file)
{
size_t n = fread(data, 1, info.st_size, file);
if (n != 0 && n <= info.st_size)
{
data[n] = 0;
result = data;
data = NULL;
}
fclose(file);
}
free(data);
}
}
return result;
}
Show your C++ code and I can tell why I dislike it.
It can be because of performance or code size or portability
or some hidden behavior or because it is too fancy together with
all the problems above.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 22:16 +0100 |
| Message-ID | <rrghra$2n4$1@dont-email.me> |
| In reply to | #157356 |
> char* readfile(const char* path)
> {
> char* result = NULL;
>
> struct stat info;
> if(stat(path, &info) == 0)
> {
> char* data = malloc(sizeof(char) * info.st_size + 1);
> if (data)
> {
> FILE* file = fopen(path, "r");
> if (file)
> {
> size_t n = fread(data, 1, info.st_size, file);
> if (n != 0 && n <= info.st_size)
> {
> data[n] = 0;
> result = data;
> data = NULL;
> }
> fclose(file);
> }
> free(data);
> }
> }
>
> return result;
> }
Absolutely more elegant:
#include <iostream>
#include <vector>
#include <filesystem>
#include <cstdint>
#include <cstring>
#include <fstream>
using namespace std;
// may throw filesystem_error
// may throw bad_alloc
// may throw ios_base::failure
vector<char> readFile( char const *path )
{
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
path + strlen( path ) ) );
vector<char> data( (size_t)fileSize + 1 );
ifstream ifs;
ifs.exceptions( ifstream::failbit | ifstream::badbit );
try
{
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
}
catch( ios_base::failure & )
{
data[(size_t)fileSize] = 0;
}
return data;
}
The only mistake I made here is that I'm on a 32 bit system with
a 64 bit filesystem. I should check if fileSize is < 0x100000000u
then.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 22:39 +0100 |
| Message-ID | <rrgj5u$b69$1@dont-email.me> |
| In reply to | #157360 |
> // may throw ios_base::failure No, caught.
[toc] | [prev] | [next] | [standalone]
| From | Thiago Adams <thiago.adams@gmail.com> |
|---|---|
| Date | 2020-12-17 13:44 -0800 |
| Message-ID | <fe8eac6c-5448-4515-a70e-246ef6d4524dn@googlegroups.com> |
| In reply to | #157360 |
On Thursday, December 17, 2020 at 6:16:42 PM UTC-3, Bonita Montero wrote:
...
> Absolutely more elegant:
>
> #include <iostream>
> #include <vector>
> #include <filesystem>
> #include <cstdint>
> #include <cstring>
> #include <fstream>
>
> using namespace std;
>
> // may throw filesystem_error
> // may throw bad_alloc
> // may throw ios_base::failure
>
> vector<char> readFile( char const *path )
> {
> uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
> path + strlen( path ) ) );
> vector<char> data( (size_t)fileSize + 1 );
> ifstream ifs;
> ifs.exceptions( ifstream::failbit | ifstream::badbit );
> try
> {
> ifs.open( path, ifstream::binary );
> ifs.read( &data[0], (size_t)fileSize );
> }
> catch( ios_base::failure & )
> {
> data[(size_t)fileSize] = 0;
> }
> return data;
> }
>
> The only mistake I made here is that I'm on a 32 bit system with
> a 64 bit filesystem. I should check if fileSize is < 0x100000000u
> then.
What is the "contract"?
When the function fails you return the allocated vector with zeros? Do I need to check
if the vector is all zeros?
Sometimes it throws so I need to check zeros and also check exceptions?
I think this version is better (just exceptions)
vector<char> readFile(char const* path)
{
uint64_t fileSize = (uint64_t)file_size(filesystem::path(path,
path + strlen(path)));
vector<char> data((size_t)fileSize + 1);
ifstream ifs;
ifs.exceptions(ifstream::failbit | ifstream::badbit);
ifs.open(path, ifstream::binary);
ifs.read(&data[0], (size_t)fileSize);
return data;
}
I think this code is slower and bigger (generated code) than the C version
and it is less portable.
C 28 lines C++ (my version) 11 lines.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-17 22:51 +0100 |
| Message-ID | <rrgjt0$g6a$2@dont-email.me> |
| In reply to | #157363 |
> When the function fails you return the allocated vector with zeros? Do I need to check
> if the vector is all zeros?
The vector is initialized with default-constructed chars, i.e. zeros.
The read could partitially fail like the read of the C-code.
> I think this code is slower and bigger (generated code) than the C version
> and it is less portable.
ifstream::read() should be equally fast because I open the stream
for binary-reading.
> C 28 lines C++ (my version) 11 lines.
Show it to me.
That's my corrected version:
#include <iostream>
#include <vector>
#include <filesystem>
#include <cstdint>
#include <cstring>
#include <fstream>
#include <limits>
using namespace std;
// may throw filesystem_error
// may throw bad_alloc
vector<char> readFile( char const *path )
{
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path +
strlen( path ) ) );
if( fileSize > numeric_limits<size_t>::max() )
throw bad_alloc();
vector<char> data( (size_t)fileSize + 1 );
ifstream ifs;
ifs.exceptions( ifstream::failbit | ifstream::badbit );
try
{
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
}
catch( ios_base::failure & )
{
data[(size_t)fileSize] = 0;
}
return data;
}
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-18 01:33 +0300 |
| Message-ID | <20201218013304.89c5c8c6b96a0c6685a8e33f@gmail.com> |
| In reply to | #157364 |
Bonita Montero:
> #include <iostream>
> #include <vector>
> #include <filesystem>
> #include <cstdint>
> #include <cstring>
> #include <fstream>
> #include <limits>
>
> using namespace std;
>
> // may throw filesystem_error
> // may throw bad_alloc
>
> vector<char> readFile( char const *path )
> {
> uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path +
> strlen( path ) ) );
> if( fileSize > numeric_limits<size_t>::max() )
> throw bad_alloc();
> vector<char> data( (size_t)fileSize + );
> ifstream ifs;
> ifs.exceptions( ifstream::failbit | ifstream::badbit );
> try
> {
> ifs.open( path, ifstream::binary );
> ifs.read( &data[0], (size_t)fileSize );
> }
> catch( ios_base::failure & )
> {
> data[(size_t)fileSize] = 0;
> }
> return data;
> }
I don't like your code at all. It has seven (!) #includes
for so simple a function. My C version needs only three. Is
it a dependency hell? Your code is cluttered with long
compound identifiers. In-place declarations mixed with
assignments make it very hard to follow because the reader
has to wade throught the clutter instead of glancing the
declaraiton at the top[1]. The very sight of :: and tag-
like <> is aesthetically displeasing to me. The first
statement is so long that your newsreader had to split it
into two lines that look outright ugly as quoted. If I re-
join the lines it becomes:
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path + strlen( path ) ) );
95 characters of repetitive clutter. The line is so long
you cannot print it in a medum-sized book. Compare it with
the line length in mine and Bart's versions. I cannot approve
of a language in which professionally written code must be so
inelegant. It would not be pleasant to look at, to read, and
to work with.
____________________
1. I did not criticise Thiago's version on the same ground
because it's over clarity.
--
() ascii ribbon campaign -- against html e-mail
/\ http://preview.tinyurl.com/qcy6mjc [archived]
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 06:54 +0100 |
| Message-ID | <rrhg6s$87b$1@dont-email.me> |
| In reply to | #157371 |
> I don't like your code at all. It has seven (!) #includes > for so simple a function. ... But it's much cleaner with RAII. > Your code is cluttered with longcompound identifiers. Doen't matter > In-place declarations mixed with assignments make it very > hard to follow because the reader has to wade throught the > clutter instead of glancing the declaraiton at the top[1]. For someone familiar with C++ it's easy to read. > The very sight of :: and tag- like <> is aesthetically > displeasing to LOL, what nonsense. > uint64_t fileSize = (uint64_t)file_size( filesystem::path( path, path + strlen( path ) ) ); filesystem::path has the advantage that you can use any charset, including Unicode.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-18 13:28 +0000 |
| Message-ID | <m82DH.75750$JT57.46464@fx31.ams4> |
| In reply to | #157377 |
On 18/12/2020 05:54, Bonita Montero wrote:
>> I don't like your code at all. It has seven (!) #includes
>> for so simple a function. ...
>
> But it's much cleaner with RAII.
>
>> Your code is cluttered with longcompound identifiers.
>
> Doen't matter
>
>> In-place declarations mixed with assignments make it very
>> hard to follow because the reader has to wade throught the
>> clutter instead of glancing the declaraiton at the top[1].
>
> For someone familiar with C++ it's easy to read.
>
>> The very sight of :: and tag- like <> is aesthetically
>> displeasing to
>
> LOL, what nonsense.
>
>> uint64_t fileSize = (uint64_t)file_size( filesystem::path(
>> path, path + strlen( path ) ) );
>
> filesystem::path has the advantage that you can use any charset,
> including Unicode.
This is your code:
vector<char> readFile( char const *path )
{
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
path + strlen( path ) ) );
if( fileSize > numeric_limits<size_t>::max() )
throw bad_alloc();
vector<char> data( (size_t)fileSize + 1 );
ifstream ifs;
ifs.exceptions( ifstream::failbit | ifstream::badbit );
try
{
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
}
catch( ios_base::failure & )
{
data[(size_t)fileSize] = 0;
}
return data;
}
Let's take it bit by bit:
vector<char> readFile( char const *path )
{
OK, readfile is a function taking a string and return an array of bytes.
uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
path + strlen( path ) ) );
I don't know whether all the bits are necessary, like the cast, or the
need to first process the given path before it can be used to call
file_size.
if( fileSize > numeric_limits<size_t>::max() )
throw bad_alloc();
Hmm, this is testing whether filesize is out of range of 'size_t'? Why?
size_t is most likely the same as uint64_t anyway.
What happens if the file doesn't exist? Is that when fileSize could be >
size_t? If so, then good luck with that!
vector<char> data( (size_t)fileSize + 1 );
So, declare a dynamic byte array, but again with an over-preoccupation
with pointless casts. How about you just declare everthing with int64;
that should cover the sizes of most files.
ifs.exceptions( ifstream::failbit | ifstream::badbit );
Don't know what this is for.
ifs.open( path, ifstream::binary );
ifs.read( &data[0], (size_t)fileSize );
Open the file binary, then read <filesize> bytes. Is the file then
closed by ifs.read? I can't tell. Interesting that you have to write
&data[0], when with normal C arrays, you just do 'data'.
catch( ios_base::failure & )
{
data[(size_t)fileSize] = 0;
This detects any errors, but which ones? But when one is detected, it
sets the last byte to 0. (FFS, what is it with all these casts?! What
happens if you leave it off?)
So if it can't find the file, how does the caller know that? Is it
supposed to 'catch' its own exception, or does it look at the last byte
of the data? If so, what is it looking for?
But given your approach, I would expect a 'better' language in the style
of C to allow you to write it more like this:
char[] readFile(char* path) {
int64 filesize = file_size(path);
char data[filesize];
ifstream ifs;
try {
ifs.open(path, binary_mode);
ifs.read(data, fileSize)
} catch (failure) {
throw(....);
}
return data;
}
I don't know how you dealt with errors on file_size(), so I've ignored
that. And I don't know how you communicate errors to the caller, so here
I've triggered another exeception to be picked up by the caller.
(I don't understand C++ exceptions. I'm assuming that if the caller
doesn't 'catch' the file exception, and neither does any code further
back, then the runtime will show an error. So the question of what is in
the returned data doesn't arise.)
The point of this however is to show how code can be written in a less
sprawling and less cluttered manner than yours, and be easier to
understand and reason about.
I can only assume that you're paid by the word to churn reams of
pointless C++ code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 15:14 +0100 |
| Message-ID | <rridgd$32p$1@dont-email.me> |
| In reply to | #157384 |
> uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
> path + strlen( path ) ) );
> I don't know whether all the bits are necessary, like the cast, or the
> need to first process the given path before it can be used to call
> file_size.
file_size returns uintmax_t, so I should have declared fileSize as
uintmax_t. But the cast is also ok.
> if( fileSize > numeric_limits<size_t>::max() )
> throw bad_alloc();
> Hmm, this is testing whether filesize is out of range of 'size_t'? Why?
> size_t is most likely the same as uint64_t anyway.
Not on 32-bit-computers.
On 64-bit-computers this check is casted away.
> What happens if the file doesn't exist? Is that when fileSize could be >
> size_t? If so, then good luck with that!
The original code returns an array with just a zero at the end if
an I/O-error happens. The vector I use is default-initialized with
zeroes so this happens automatically.
> vector<char> data( (size_t)fileSize + 1 );
> So, declare a dynamic byte array, but again with an over-preoccupation
> with pointless casts. How about you just declare everthing with int64;
> that should cover the sizes of most files.
No the cast isn't pointless on 32-bit-systems.
> ifs.exceptions( ifstream::failbit | ifstream::badbit );
> Don't know what this is for.
streams don't throw exceptions by default. This makes generating
exceptions for the failbit and the badbit.
> ifs.open( path, ifstream::binary );
> ifs.read( &data[0], (size_t)fileSize );
> Open the file binary, then read <filesize> bytes. Is the file then
> closed by ifs.read?
The file is closed automatically via RAII.
> I can't tell. Interesting that you have to write
> &data[0], when with normal C arrays, you just do 'data'.
Is the shortest way to get a pointer inside the array.
Otherwise I could have writtten &*data.begin().
>
> catch( ios_base::failure & )
> {
> data[(size_t)fileSize] = 0;
> This detects any errors, but which ones?
All relevant I/O-errors.
> But when one is detected, it sets the last byte to 0.
... like the original C-code.
> So if it can't find the file, how does the caller know that?
The original C-code doesn't do this as well. If the read doesn't
read until the end it returns a block with a terimating zero.
> Is it supposed to 'catch' its own exception, or does it look
> at the last byte of the data? If so, what is it looking for?
You neither understand the C-code nor the C++-code.
> But given your approach, I would expect a 'better' language in the style
> of C to allow you to write it more like this:
> char[] readFile(char* path) {
> int64 filesize = file_size(path);
file_size doesn't accept a filename as a zero-terminated string;
you would have to give a std::filesystem::path-object. This is
to support different charsets like Unicode.
> char data[filesize];
LOL, this gives a stack-overflow easily.
> ifstream ifs;
You must enable the exceptions.
> try {
> ifs.open(path, binary_mode);
> ifs.read(data, fileSize)
> } catch (failure) {
> throw(....);
If you do it that way you could completely omit the try/catch-clause.
> }
> return data;
> }
> I don't know how you dealt with errors on file_size(), ...
I documented the exception that file_size might throw.
> The point of this however is to show how code can be written in a less
> sprawling and less cluttered manner than yours, and be easier to
> understand and reason about.
C++ is much cleaner.
> I can only assume that you're paid by the word to churn reams of
> pointless C++ code.
Your code is buggy, mine is ok.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 15:16 +0100 |
| Message-ID | <rridj4$32p$2@dont-email.me> |
| In reply to | #157388 |
>> char data[filesize]; > LOL, this gives a stack-overflow easily. And this might be supported by some compilers, but it is not C++ because C++ doesn't support VLAs.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-18 16:19 +0000 |
| Message-ID | <nE4DH.188924$SiR9.37365@fx11.ams4> |
| In reply to | #157388 |
On 18/12/2020 14:14, Bonita Montero wrote:
>> uint64_t fileSize = (uint64_t)file_size( filesystem::path( path,
>> path + strlen( path ) ) );
>> I don't know whether all the bits are necessary, like the cast, or the
>> need to first process the given path before it can be used to call
>> file_size.
>
> file_size returns uintmax_t, so I should have declared fileSize as
> uintmax_t. But the cast is also ok.
Having about being done with all myriad variations of the same 4 int
types; just have int32/64, uint32/64. And for file sizes and array
dimensions, just use int64.
>
>
>> if( fileSize > numeric_limits<size_t>::max() )
>> throw bad_alloc();
>> Hmm, this is testing whether filesize is out of range of 'size_t'?
>> Why? size_t is most likely the same as uint64_t anyway.
>
> Not on 32-bit-computers.
> On 64-bit-computers this check is casted away.
OK. I forgot it's only been a decade or so that you haven't been able to
buy a 32-bit computer.
>> What happens if the file doesn't exist? Is that when fileSize could be
>> > size_t? If so, then good luck with that!
>
> The original code returns an array with just a zero at the end if
> an I/O-error happens. The vector I use is default-initialized with
> zeroes so this happens automatically.
I meant when you call file_size() using the path of a non-existent file.
What value does it return? (Not that in my C version, the file size of a
currently open file.)
> You neither understand the C-code nor the C++-code.
Whose C-code; I understand mine. And I understand the task.
>
>> But given your approach, I would expect a 'better' language in the
>> style of C to allow you to write it more like this:
>> char[] readFile(char* path) {
>> int64 filesize = file_size(path);
> file_size doesn't accept a filename as a zero-terminated string;
> you would have to give a std::filesystem::path-object. This is
> to support different charsets like Unicode.
>> char data[filesize];
> LOL, this gives a stack-overflow easily.
The return type is 'char[]' which is supposed to represent a flexible
char-array equivalent to 'vector<char>' but with better syntax.
This declares that same type and creates an instance using the given
size. It is not a C VLA.
>> ifstream ifs;
> You must enable the exceptions.
>> try {
>> ifs.open(path, binary_mode);
>> ifs.read(data, fileSize)
>> } catch (failure) {
>> throw(....);
> If you do it that way you could completely omit the try/catch-clause.
>
>> }
>> return data;
>> }
>
>> I don't know how you dealt with errors on file_size(), ...
>
> I documented the exception that file_size might throw.
You didn't document it too well, as I have no idea what execution path
is taken when file_size fails.
(file-size will most likely fail for the same reason as open() - file
not found.)
>> The point of this however is to show how code can be written in a less
>> sprawling and less cluttered manner than yours, and be easier to
>> understand and reason about.
>
> C++ is much cleaner.
C++ could be considerably cleaner than the way you write it. But take
this line from your original:
if( fileSize > numeric_limits<size_t>::max() ) ...
I don't know if the verbosity is entirely due to C++. In my language
(assuming size_t is uint64), if would be written as:
if filesize > word.max then ...
Half the number of tokens. But surely even C++ would have something like
size_t.max() ?
>> I can only assume that you're paid by the word to churn reams of
>> pointless C++ code.
>
> Your code is buggy, mine is ok.
My code is in a fantasy version of C++.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 17:26 +0100 |
| Message-ID | <rril7c$tec$1@dont-email.me> |
| In reply to | #157395 |
> Having about being done with all myriad variations of the same 4 int > types; just have int32/64, uint32/64. And for file sizes and array > dimensions, just use int64. intmax_t would be the most appropriate since it is the native return-type of file_size. > I meant when you call file_size() using the path of a non-existent file. Then std::filesystem::filesystem_error is trown. > The return type is 'char[]' which is supposed to represent a flexible > char-array equivalent to 'vector<char>' but with better syntax. The stack is 1MB on Windows and 2MB on Linux per default; that's not much. And you're returning the address within the stack which is invalid when you return. > You didn't document it too well, as I have no idea what execution path > is taken when file_size fails. I had given a comment with the filesystem_errore-exception which might be thrown on my post where I've shown the first version of my code. > C++ could be considerably cleaner than the way you write it. You made a lot of mistakes in your code so don't think you can judge on this. > But take this line from your original: > if( fileSize > numeric_limits<size_t>::max() ) ... > I don't know if the verbosity is entirely due to C++. In my language > (assuming size_t is uint64), if would be written as: size_t isn't a fixed size so im referring to the implementation -defined maximum which is defined in <limits> > if filesize > word.max then ... > Half the number of tokens. But wrong code depending on which platform you compile. > But surely even C++ would have something like size_t.max() ? size_t isn't an object.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-18 17:07 +0000 |
| Message-ID | <Cl5DH.145448$oT47.133495@fx20.ams4> |
| In reply to | #157397 |
On 18/12/2020 16:26, Bonita Montero wrote:
>> Having about being done with all myriad variations of the same 4 int
>> types; just have int32/64, uint32/64. And for file sizes and array
>> dimensions, just use int64.
>
> intmax_t would be the most appropriate since it is the native
> return-type of file_size.
Once you have int64 then there is little point to all those other sizes
except as storage types used in arrays and structs.
>> But take this line from your original:
>> if( fileSize > numeric_limits<size_t>::max() ) ...
>> I don't know if the verbosity is entirely due to C++. In my language
>> (assuming size_t is uint64), if would be written as:
>
> size_t isn't a fixed size so im referring to the implementation
> -defined maximum which is defined in <limits>
>
>> if filesize > word.max then ...
>> Half the number of tokens.
>
> But wrong code depending on which platform you compile.
It doesn't matter. I used to have a type called 'wordm', which was
either u32 or u64 depending on platform. But since I concentrated on
64-bit targts, I don't have to worry about such details.
>
>> But surely even C++ would have something like size_t.max() ?
>
> size_t isn't an object.
That doesn't matter either. This is more about how C++ could and should
work.
What can be simpler than allowing T.min and T.max, where T is any type?
My main language allows this:
int a
println a.max
println int.max
println a.typestr
Output is:
9223372036854775807
9223372036854775807
i64
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 18:18 +0100 |
| Message-ID | <rrio9o$l6j$1@dont-email.me> |
| In reply to | #157400 |
>> intmax_t would be the most appropriate since it is the native >> return-type of file_size. > Once you have int64 then there is little point to all those other sizes > except as storage types used in arrays and structs. intmax_t is the nativ return-type of file_size so it's the most portable type. >>> if filesize > word.max then ... >>> Half the number of tokens. >> But wrong code depending on which platform you compile. > It doesn't matter. I used to have a type called 'wordm', which was > either u32 or u64 depending on platform. ... There isn't something like word.max in C++ and you havent declared an object which is called word. So this code doesn't make sense. Using numeric_limit<size_t>:max() is the most portbale solution in C++. >>> But surely even C++ would have something like size_t.max() ? >> size_t isn't an object. > That doesn't matter either. This is more about how C++ could and should > work. It doesn't work since size_t is derived from a native type and native types don't have methos. > My main language allows this: > int a > println a.max > println int.max > println a.typestr We're talking about either C or C++, but not about a phantasy-language.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-18 18:34 +0000 |
| Message-ID | <0D6DH.628865$W6Df.477662@fx12.ams4> |
| In reply to | #157401 |
On 18/12/2020 17:18, Bonita Montero wrote:
>> It doesn't matter. I used to have a type called 'wordm', which was
>> either u32 or u64 depending on platform. ...
>
> There isn't something like word.max in C++ and you havent declared
> an object which is called word.
'word' is what I call uint64 or u64.
>> That doesn't matter either. This is more about how C++ could and
>> should work.
>
> It doesn't work since size_t is derived from a native type and
> native types don't have methos.
So, forget methods and just do whatever you need to get the limits of a
type.
>> My main language allows this:
>> int a
>> println a.max
>> println int.max
>> println a.typestr
>
> We're talking about either C or C++, but not about a phantasy-language.
This example is my everyday language, it's not a fantasy.
And it is about getting the maximum value an integer type T or
expression X can have. There is no reason why a language needs to have
anything beyond T.max or max(T) or anything along those lines.
Yet C++ seems to need:
std::numeric_limit<T>::max()
10 tokens? Come on! Why is everything in C++ so complicated, so
long-winded, and so freaking ugly?
And if I wanted to do X.max, I'd have to write:
std::numeric_limit<typeof(X)>::max()
13 tokens this time!
If I to wanted to ensure that X was in the range of int32, I'd have to
write:
if (X>=std::numeric_limit<int32>::min() &&
X<=std::numeric_limit<int32>::max())
28 tokens if I counted correctly (and X is written/evaluated twice). I
currently write:
if X in int32.min..int32.max then
which is 10 tokens, and I also allow:
if X in int32.range then
which reduces it to 7. Here, int32 as well as X is written only once.
I think you can keep your C++ ...
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 20:40 +0100 |
| Message-ID | <rrj0j7$lbo$1@dont-email.me> |
| In reply to | #157408 |
>> There isn't something like word.max in C++ and you havent declared >> an object which is called word. > 'word' is what I call uint64 or u64. We're talking about C or c++. >> It doesn't work since size_t is derived from a native type and >> native types don't have methos. > So, forget methods and just do whatever you need to get the limits of a > type. I did it the right way with numeric_limits<size_t>::max(). >> We're talking about either C or C++, but not about a phantasy-language. > This example is my everyday language, it's not a fantasy. Where's the compiler ? > Yet C++ seems to need: > std::numeric_limit<T>::max() > > 10 tokens? Come on! Why is everything in C++ so complicated, so > long-winded, and so freaking ugly? That's neither complicated, nor long-windet, not ugly, but readable. > And if I wanted to do X.max, I'd have to write: > std::numeric_limit<typeof(X)>::max() No, numeric_limits<decltype(X)>::max(). > 13 tokens this time! That's more readable than word...whatever. > If I to wanted to ensure that X was in the range of int32, I'd have to > write: > if (X>=std::numeric_limit<int32>::min() && > X<=std::numeric_limit<int32>::max()) > 28 tokens if I counted correctly (and X is written/evaluated twice). I > currently write: That expressivenes makes the language readable. The quality of a language can't be assessed on how short you can express something. > if X in int32.min..int32.max then > which is 10 tokens, and I also allow: > if X in int32.range then In your phantasy-language.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-18 21:16 +0000 |
| Message-ID | <K_8DH.1111018$PJla.769760@fx46.ams4> |
| In reply to | #157414 |
On 18/12/2020 19:40, Bonita Montero wrote: >>> We're talking about either C or C++, but not about a phantasy-language. > >> This example is my everyday language, it's not a fantasy. > > Where's the compiler ? http://www.bcas.freeuk.com/bb.exe but it runs on Windows-64 and targets Windows-64. >> Yet C++ seems to need: >> std::numeric_limit<T>::max() >> >> 10 tokens? Come on! Why is everything in C++ so complicated, so >> long-winded, and so freaking ugly? > > That's neither complicated, nor long-windet, not ugly, but readable. It's a lot more long-winded than 3 tokens. >> And if I wanted to do X.max, I'd have to write: >> std::numeric_limit<typeof(X)>::max() > > No, numeric_limits<decltype(X)>::max(). numeric_limits is part of the std namespace. You can only omit the std:: is you've previously written 'using namespace std;'. Not everyone will do that, so lots of C++ code of others will have std::. > >> 13 tokens this time! > > That's more readable than word...whatever. > >> If I to wanted to ensure that X was in the range of int32, I'd have to >> write: >> if (X>=std::numeric_limit<int32>::min() && >> X<=std::numeric_limit<int32>::max()) >> 28 tokens if I counted correctly (and X is written/evaluated twice). I >> currently write: > > That expressivenes makes the language readable. You're having a laugh, surely? >> if X in int32.min..int32.max then >> which is 10 tokens, and I also allow: >> if X in int32.range then > > In your phantasy-language. Actually it doesn't matter. If you are designing a way in a language to pick up the numeric range or limits of a type, this is the minimum amount that needs to be written: (1) The type involved; (2) the property to extract; (3) whatever glue syntax the language specifies. In my case, (3) amounts to a single dot, and a single character. In C++, (3) requires "std", "::", "numeric_limits", "<", ">" and "()", some 23 characters. That's on top of an already ugly type name like "size_t". That looks like poor language design to me, a pain to write, read and maintain, and with lots more opportunities for typos.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 22:24 +0100 |
| Message-ID | <rrj6lt$1hg$1@dont-email.me> |
| In reply to | #157423 |
>>> 10 tokens? Come on! Why is everything in C++ so complicated, so >>> long-winded, and so freaking ugly? >> That's neither complicated, nor long-windet, not ugly, but readable. > It's a lot more long-winded than 3 tokens. The number of characters is not a criteria for the quality of a lanugage. And you can be sure that C++ is magnitudes more flexible than your idiotic langiage. > numeric_limits is part of the std namespace. You can only omit the std:: > is you've previously written 'using namespace std;'. Not everyone will > do that, so lots of C++ code of others will have std::. selecting std via using is common, except in headers outside functions where you won't pre-select std for someone that uses this header. >>> If I to wanted to ensure that X was in the range of int32, I'd have >>> to write: >>> if (X>=std::numeric_limit<int32>::min() && >>> X<=std::numeric_limit<int32>::max()) >>> 28 tokens if I counted correctly (and X is written/evaluated twice). >>> I currently write: >> That expressivenes makes the language readable. > You're having a laugh, surely? Sorry, this language is to complicated for your small mind. > Actually it doesn't matter. If you are designing a way in a language to > pick up the numeric range or limits of a type, this is the minimum > amount that needs to be written: (1) The type involved; (2) the property > to extract; (3) whatever glue syntax the language specifies. The expressiveness of what is needed here in C++ makes it more readable. > In C++, (3) requires "std", "::", "numeric_limits", "<", ">" and "()", > some 23 characters. That's on top of an already ugly type name like > "size_t". Sorry, you're ultimately infantile stupid.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-18 21:50 +0000 |
| Message-ID | <20201218135007.724@kylheku.com> |
| In reply to | #157424 |
On 2020-12-18, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>>> 10 tokens? Come on! Why is everything in C++ so complicated, so >>>> long-winded, and so freaking ugly? > >>> That's neither complicated, nor long-windet, not ugly, but readable. > >> It's a lot more long-winded than 3 tokens. > > The number of characters is not a criteria for the quality of a > lanugage. It absolutely is. All else being equal, a monstrously verbose language is objectively worse than a succinct one.
[toc] | [prev] | [next] | [standalone]
Page 8 of 15 — ← Prev page 1 … 6 7 [8] 9 10 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web