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 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-18 23:25 +0100 |
| Message-ID | <rrja8f$pdr$1@dont-email.me> |
| In reply to | #157425 |
>> The number of characters is not a criteria for the quality of a >> lanugage. > It absolutely is. ... Yes, for compulsive people.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-19 01:01 +0000 |
| Message-ID | <FhcDH.909366$OEna.808576@fx49.ams4> |
| In reply to | #157424 |
On 18/12/2020 21:24, Bonita Montero 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. And you can be sure that C++ is magnitudes more flexible
> than your idiotic langiage.
NEEDLESS characters is a big factor. I have plenty of problems with C on
that score, but C++ is off the scale.
Minor example, to print 3 variables with the name of each shown:
Mine:
println =a, =b, =c
C:
printf("A=%lld B=%f C%s\n", a, b, c);
C++:
std::cout << "A=" << a << " B=" << b << " C=" << c << std::endl;
cout << "A=" << a << " B=" << b << " C=" << c << endl;
The C is bad enough (and there's a big problem in having to keep on top
of the format codes), but look at the C++. Even without the std::, it's
longer than the C!
(And you can't always just use printf from C++, if the types are not
supported.)
Which would you rather type for a quick debug print?
>>> That expressivenes makes the language readable.
>
>> You're having a laugh, surely?
>
> Sorry, this language is to complicated for your small mind.
It's just too complicated. Everyone knows that.
And it seems to encourage over-the-top solutions such as most of the C++
you post here.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 11:47 +0100 |
| Message-ID | <rrkln4$1oe$2@dont-email.me> |
| In reply to | #157437 |
> NEEDLESS characters is a big factor. I have plenty of problems with C on > that score, but C++ is off the scale. You're stupid.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-19 02:45 +0000 |
| Message-ID | <20201218184405.375@kylheku.com> |
| In reply to | #157424 |
On 2020-12-18, Bonita Montero <Bonita.Montero@gmail.com> wrote: > BartC: >> You're having a laugh, surely? > > Sorry, this language is to complicated for your small mind. How confident would you be to take a closed-book C++ exam covering most of the 1600+ pages of it? -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 11:48 +0100 |
| Message-ID | <rrklpp$1oe$3@dont-email.me> |
| In reply to | #157439 |
>> Sorry, this language is to complicated for your small mind. > How confident would you be to take a closed-book C++ exam covering > most of the 1600+ pages of it? But C++ has ne best combination of flexibility, lowlevel- and highlevel-facilities and keeping performance yet.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2020-12-19 12:13 +0000 |
| Message-ID | <P7mDH.76415$JT57.2448@fx31.ams4> |
| In reply to | #157442 |
On 19/12/2020 10:48, Bonita Montero wrote: >>> Sorry, this language is to complicated for your small mind. > >> How confident would you be to take a closed-book C++ exam covering >> most of the 1600+ pages of it? > > But C++ has ne best combination of flexibility, lowlevel- > and highlevel-facilities and keeping performance yet. Yes, and the result is a big, ugly, unwieldy mess of a language. One in which people can't resist using every possible toy as your programs demonstrate.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-19 13:33 +0100 |
| Message-ID | <rrkrv7$bc8$1@dont-email.me> |
| In reply to | #157447 |
>> But C++ has ne best combination of flexibility, lowlevel- >> and highlevel-facilities and keeping performance yet. > Yes, and the result is a big, ugly, unwieldy mess of a language. That's not true. C++ has some edges, but ist mostly very elegant.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-19 20:24 +0000 |
| Message-ID | <20201219122304.385@kylheku.com> |
| In reply to | #157442 |
On 2020-12-19, Bonita Montero <Bonita.Montero@gmail.com> wrote: >>> Sorry, this language is to complicated for your small mind. > >> How confident would you be to take a closed-book C++ exam covering >> most of the 1600+ pages of it? > > But C++ has ne best combination of flexibility, lowlevel- > and highlevel-facilities and keeping performance yet. I coined a new neo-Latin word today: non-sequiturd. -- TXR Programming Language: http://nongnu.org/txr
[toc] | [prev] | [next] | [standalone]
| From | Anton Shepelev <anton.txt@gmail.com> |
|---|---|
| Date | 2020-12-19 17:28 +0300 |
| Message-ID | <20201219172815.ee4d88edb9bc19c3b03614f5@gmail.com> |
| In reply to | #157424 |
Bonita Montero about C++:
> Sorry, this language is to complicated for your small
> mind.
An overly complicated language is like an OS that takes all
the RAM and CPU avaiable, leaving no resources for actual
work. C.f. the great Edsger Dijkstra:
-- The competent programmer is fully aware of the limited
size of his own skull. He therefore approaches his task
with full humility, and avoids clever tricks like the
plague.
-- Simplicity is a great virtue but it requires hard work
to achieve it and education to appreciate it. And to
make matters worse: complexity sells better.
-- Simplicity is prerequisite for reliability.
-- The traditional mathematician recognizes and
appreciates mathematical elegance when he sees it. I
propose to go one step further, and to consider
elegance an essential ingredient of mathematics: if it
is clumsy, it is not mathematics.
-- Elegance is not a dispensable luxury but a factor that
decides between success and failure.
-- Why has elegance found so little following? That is the
reality of it. Elegance has the disadvantage, if that's
what it is, that hard work is needed to achieve it and
a good education to appreciate it.
-- Object-oriented programming is an exceptionally bad
idea which could only have originated in California.
--
() 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-19 16:05 +0100 |
| Message-ID | <rrl4r1$86k$1@dont-email.me> |
| In reply to | #157460 |
>> Sorry, this language is to complicated for your small >> mind. > An overly complicated language is like an OS that takes all > the RAM and CPU avaiable, leaving no resources for actual > work. C.f. the great Edsger Dijkstra: A complicated language has nothing to do with runtime-overhead. It's hard to become a good C++-programmer, but if you have managed it, you have the best combination of performance, abstraction and flexibility. > -- Simplicity is a great virtue but it requires hard work > to achieve it and education to appreciate it. And to > make matters worse: complexity sells better. > -- Simplicity is prerequisite for reliability. When you comare C++ and C it's by far easier to gain reliability in C++ if you have managed to understand the language. > -- The traditional mathematician recognizes and > appreciates mathematical elegance when he sees it. I > propose to go one step further, and to consider > elegance an essential ingredient of mathematics: if it > is clumsy, it is not mathematics. That can be transferred to programming-language because there's nothing to gain from abstraction in mathematics. In C++ there's a lot of abs- traction over C and that makes it easier to manage complex code. > -- Elegance is not a dispensable luxury but a factor that > decides between success and failure. > -- Why has elegance found so little following? That is the > reality of it. Elegance has the disadvantage, if that's > what it is, that hard work is needed to achieve it and > a good education to appreciate it. C++ is more elegant than C. > -- Object-oriented programming is an exceptionally bad > idea which could only have originated in California. That comes from people which are too stupid to understand OOP. OOP is not a panacea, but one of the most essential ingredients of a programming-language.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2020-12-24 21:55 -0800 |
| Message-ID | <86bleixwdc.fsf@linuxsc.com> |
| In reply to | #157460 |
Anton Shepelev <anton.txt@gmail.com> writes: > Bonita Montero about C++: > >> Sorry, this language is to complicated for your small >> mind. > > An overly complicated language is like an OS that takes all > the RAM and CPU avaiable, leaving no resources for actual > work. C.f. the great Edsger Dijkstra: > [...] > > -- Object-oriented programming is an exceptionally bad > idea which could only have originated in California. I greatly respect the views of Dijkstra, but on this point he is simply wrong: the idea of object-oriented programming did not originate in California.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2020-12-25 05:26 -0800 |
| Message-ID | <89afb76d-163a-4478-b44c-a49aaeefd9b9n@googlegroups.com> |
| In reply to | #157727 |
On Friday, December 25, 2020 at 7:56:04 AM UTC+2, Tim Rentsch wrote: > Anton Shepelev <anto...@gmail.com> writes: > > > Bonita Montero about C++: > > > >> Sorry, this language is to complicated for your small > >> mind. > > > > An overly complicated language is like an OS that takes all > > the RAM and CPU avaiable, leaving no resources for actual > > work. C.f. the great Edsger Dijkstra: > > [...] > > > > -- Object-oriented programming is an exceptionally bad > > idea which could only have originated in California. > > I greatly respect the views of Dijkstra, but on this point > he is simply wrong: the idea of object-oriented programming > did not originate in California. So, I suppose, you agree with the first part of his sentence?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-25 14:28 +0100 |
| Message-ID | <rs4pd5$jq5$1@dont-email.me> |
| In reply to | #157738 |
>>> -- Object-oriented programming is an exceptionally bad >>> idea which could only have originated in California. >> I greatly respect the views of Dijkstra, but on this point >> he is simply wrong: the idea of object-oriented programming >> did not originate in California. > So, I suppose, you agree with the first part of his sentence? Whereever it came from - calling OOP stupid is a stupid idea.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2020-12-25 05:38 -0800 |
| Message-ID | <1decdf57-2a59-4cda-8d42-8a43af1724a6n@googlegroups.com> |
| In reply to | #157739 |
On Friday, December 25, 2020 at 3:28:20 PM UTC+2, Bonita Montero wrote: > >>> -- Object-oriented programming is an exceptionally bad > >>> idea which could only have originated in California. > > >> I greatly respect the views of Dijkstra, but on this point > >> he is simply wrong: the idea of object-oriented programming > >> did not originate in California. > > > So, I suppose, you agree with the first part of his sentence? > Whereever it came from - calling OOP stupid is a stupid idea. Some parts of what's today considered OOP are stupid, others are not. Stupid ideas - constructors that can fail - implementation inheritance (as opposed to interface inheritance) - language-enforced encapsulation (as opposed to python-like conventions based encapsulation) I am not an historian but would think that at least the 3rd of my list of bad ideas indeed originated in California.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-25 14:51 +0100 |
| Message-ID | <rs4qol$sl6$1@dont-email.me> |
| In reply to | #157740 |
> - constructors that can fail Initializing a data structure in C may also fail. But in C++ you have exceptions that unbuild everything that has been built in the object. > - implementation inheritance (as opposed to interface inheritance) That may be used not so often but when you use it it makes sense. F.e I've just written a class which scans directories recursively wth one thread per subdir (limited to a uppper bound of a thread pool) and hands matching files to a pure virtual function that will be overridden by a subclass. > - language-enforced encapsulation (as opposed to python-like conventions based encapsulation) Conventional encapsulation makes sense. It informs the reader of a class which interface he can't touch and which interface he shouldn't read.
[toc] | [prev] | [next] | [standalone]
| From | Kaz Kylheku <563-365-8930@kylheku.com> |
|---|---|
| Date | 2020-12-25 20:00 +0000 |
| Message-ID | <20201225104610.374@kylheku.com> |
| In reply to | #157742 |
On 2020-12-25, Bonita Montero <Bonita.Montero@gmail.com> wrote: >> - constructors that can fail > > Initializing a data structure in C may also fail. > But in C++ you have exceptions that unbuild everything that > has been built in the object. I disagree also. Failing construction is a domain problem; OOP inherits the issue and has to deal with it somehow. In high level languages (going back to Lisp), memory allocation and construction are not separated like in C and C++. The original constructor is the CONS function for creating a cell. It allocates the memory and initializes it. There are no two steps like allocate an uninitialized cell and then put contents in it. If construction a new object subsumes allocating it, then any construction can fail due to out of memory. Failing due to not being able to get other necessary resources is just a generalization of that. Separating object construction into getting the memory (which can fail) and then some initialization step that can often be trivialized (since it can often consist of just stuffing bits into locations in the object) is not how clean up the concept of construction. > >> - implementation inheritance (as opposed to interface inheritance) > > That may be used not so often but when you use it it makes sense. F.e Firstly, in high level OOP languages, implementation inheritance is the only kind of inheritance. The reason is that inheritance is not required in order to write two or more classes whose instances are substitutable for one another (i.e conform to the same interface). You don't have to declare anything: you just define the classes and write the methods to be compatible, and that's it. "interface inheritance" is just a static typing mechanism present in languages like Java. Objects are handled via statically typed references. To make instances of two classes substitutable, you have to beg for permission from the compiler by declaring inheritance from interfaces. The statically typed references you use the incorporate the permission obtained from the interface, and the compiler allows the substitution. If you say that "implementation inheritance is bad", you're simply rejecting OOP inheritance as such; "interface inheritance" is not a substitute for it all. If you use nothing but interface inheritance in a Java program, that program can be rewritten in Lisp, Smalltalk, Python or Ruby without any inheritance at all. Inheritance is an important philosophical part of OOP which goes hand in hand with object substitutability. Why do we create objects that are substituable for one another? We do this for one reason only: so that we can then write pieces of code that work with different kinds of objects in some common way, allowing the central concept in some calculation or process to be re-used in a different contexts, like a meme. This is generic programming. If we make objects substitutable, but do no generic programming with them, we have wasted effort. Without substitutablity we can still use classes, but in an "object-based" way just to modularize the program. Inheritance supports code reuse which goes hand-in-hand with generic programming. So that is to say, code re-uses best when it is generic. The two ideas are in tension, like yin and yang. We laboriously write type-specific code that conforms to an interface (declared or not), so that other code elsewhere then does not have to be writen multiple times. Then, to borrow that code that doesn't have to be written multiple times, what OOP mechanism can we use? Inheritance. Inheritance is not in competition with interface inheritance, but rather with the straightforward use of other objects: collaboration. In a class Y, we can reuse the code of some other class X not just by inheriting from Y but by including a member of type X as a member in Y (aggregation) or by passing X objects into Y's methods. When condidering inheritance, we should ask the questions, "is this easily achieved by just having an object whose methods can be called, rather than bringing those methods into this object? Can that object just be an argument we pass around, or do we make it a member?" > I've just written a class which scans directories recursively wth one > thread per subdir (limited to a uppper bound of a thread pool) and > hands matching files to a pure virtual function that will be overridden > by a subclass. Thus, the base class code is generic: it can work with any properly developed implemnentation of the virtual function. Why not reuse it by inheritance? The alternative approach (based on asking the above questions) would be for this traversal object to be entirely concrete. Instead of the virtual function, its traversal method can take a function object (or perhaps a visitor object with multiple methods) as a callback. The directory traversal class is then reused not by inheritance, but by binding instances of it with visitors of different kinds. Then, do we allow the same recursive traversal instance to be repeated with differen visitors? If so, then the visitor could just be an argument. If not, we can bind it with the traverser when the traverser is constructed.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-26 12:19 +0100 |
| Message-ID | <rs767s$i9s$1@dont-email.me> |
| In reply to | #157751 |
> In high level languages (going back to Lisp), memory allocation and > construction are not separated like in C and C++. Allocation and construction is one step from the programmer's view in C++, f.e. "new string( "hello world" )". > The original > constructor is the CONS function for creating a cell. It allocates the > memory and initializes it. There are no two steps like allocate an > uninitialized cell and then put contents in it. In C there is. > If you say that "implementation inheritance is bad", ... I didn't say this. I just say that implementation-inheritance makes it obsolete often. > Inheritance supports code reuse which goes hand-in-hand with generic > programming. So that is to say, code re-uses best when it is generic. Inheritance and generic programming aren't sustitutable most times. > The alternative approach (based on asking the above questions) would > be for this traversal object to be entirely concrete. Instead of the > virtual function, its traversal method can take a function object (or > perhaps a visitor object with multiple methods) as a callback. Generic programming in this way makes sense if the overhead of the virtual fuction would be worth mentioning. But in most cases it isn't. > Then, do we allow the same recursive traversal instance to be repeated > with differen visitors? If so, then the visitor could just be an argument. > If not, we can bind it with the traverser when the traverser is > constructed. That's not necessary here.
[toc] | [prev] | [next] | [standalone]
| From | Öö Tiib <ootiib@hot.ee> |
|---|---|
| Date | 2020-12-26 19:10 -0800 |
| Message-ID | <c9cdeb02-34da-4de6-a5f2-be8ad24afb1dn@googlegroups.com> |
| In reply to | #157742 |
On Friday, 25 December 2020 at 15:51:33 UTC+2, Bonita Montero wrote: > That may be used not so often but when you use it it makes sense. F.e > I've just written a class which scans directories recursively wth one > thread per subdir (limited to a uppper bound of a thread pool) and > hands matching files to a pure virtual function that will be overridden > by a subclass. It sounds like you designed a pool of threads to compete with each other over media access? Usually media is slower than threads so those perhaps just wait.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2020-12-27 05:28 +0100 |
| Message-ID | <rs92hd$cpe$1@dont-email.me> |
| In reply to | #157804 |
>> That may be used not so often but when you use it it makes sense. F.e >> I've just written a class which scans directories recursively wth one >> thread per subdir (limited to a uppper bound of a thread pool) and >> hands matching files to a pure virtual function that will be overridden >> by a subclass. > It sounds like you designed a pool of threads to compete with each other > over media access? Usually media is slower than threads so those > perhaps just wait. The threads will wait in the kernel for media-access, so I have a lot of them to saturate the CPU.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2020-12-25 05:42 -0800 |
| Message-ID | <1eefb1fa-332d-4cd9-b89b-79e915b57951n@googlegroups.com> |
| In reply to | #157739 |
On Friday, December 25, 2020 at 3:28:20 PM UTC+2, Bonita Montero wrote: > >>> -- Object-oriented programming is an exceptionally bad > >>> idea which could only have originated in California. > > >> I greatly respect the views of Dijkstra, but on this point > >> he is simply wrong: the idea of object-oriented programming > >> did not originate in California. > > > So, I suppose, you agree with the first part of his sentence? > Whereever it came from - calling OOP stupid is a stupid idea. BTW, in my case it took me 20 years to understand that significant parts of OOP propaganda that I was subjected to in early nineties were bad ideas. Back, being of your age, I was unable of critical thinking.
[toc] | [prev] | [next] | [standalone]
Page 9 of 15 — ← Prev page 1 … 7 8 [9] 10 11 … 15 Next page →
Back to top | Article view | comp.lang.c
csiph-web