Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > comp.lang.c > #157279 > unrolled thread

A defer mechanism for C

Started byThiago Adams <thiago.adams@gmail.com>
First post2020-12-15 13:57 -0800
Last post2020-12-21 22:17 +0100
Articles 20 on this page of 300 — 18 participants

Back to article view | Back to comp.lang.c


Contents

  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 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15  Next page →


#157743

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-25 14:52 +0100
Message-ID<rs4qr5$sl6$2@dont-email.me>
In reply to#157741
> 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.

OOP is no propaganda but the most siginficant ingredient of a
programming language after structured programming. People which
are unable to think OOP can not program.

[toc] | [prev] | [next] | [standalone]


#157778

FromMalcolm McLean <malcolm.arthur.mclean@gmail.com>
Date2020-12-26 02:29 -0800
Message-ID<d0b2e559-f0e2-484a-9d76-59558a4fe7a5n@googlegroups.com>
In reply to#157743
On Friday, 25 December 2020 at 13:52:50 UTC, Bonita Montero wrote:
> > 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.
> OOP is no propaganda but the most siginficant ingredient of a 
> programming language after structured programming. People which 
> are unable to think OOP can not program.
>
One of the problem with programming methods in general is that
people who advocate them tend to adopt a bullying tone. If
you don't follow the methods, you are stupid, you can't program
correctly, etc.

If you are a manager and you are responsible for people you are
paying then you do have a reasonable expectation of co-operation
from the people who are responsible for. So if the project is using OO,
everyone has to make sure their OO skils are up to speed an pull
together to make it work.

However if you are simply discussing OO in a forum like comp.lang..c,
which is about a language that doesn't even have OO support,
then shouting down people who express dissent is inappropriate.
Object orientation has been around for a long time now. It clearly
hasn't solved the problems we have as an industry  in delivering large 
systems that function correctly on time and within budget.

[toc] | [prev] | [next] | [standalone]


#157779

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-26 12:11 +0100
Message-ID<rs75p1$eo1$1@dont-email.me>
In reply to#157778
> However if you are simply discussing OO in a forum like comp.lang..c,
> which is about a language that doesn't even have OO support,
> then shouting down people who express dissent is inappropriate.
> Object orientation has been around for a long time now. It clearly
> hasn't solved the problems we have as an industry  in delivering
> large systems that function correctly on time and within budget.

That it didn't sole all problems oft software development doesn't
mean that it isn't a useful aid in strucutring a project.

[toc] | [prev] | [next] | [standalone]


#157794

FromMalcolm McLean <malcolm.arthur.mclean@gmail.com>
Date2020-12-26 09:33 -0800
Message-ID<9a2f5ec4-92f0-4307-a9eb-9b7a5bcd44fen@googlegroups.com>
In reply to#157779
On Saturday, 26 December 2020 at 11:11:44 UTC, Bonita Montero wrote:
> > However if you are simply discussing OO in a forum like comp.lang..c, 
> > which is about a language that doesn't even have OO support, 
> > then shouting down people who express dissent is inappropriate. 
> > Object orientation has been around for a long time now. It clearly 
> > hasn't solved the problems we have as an industry in delivering 
> > large systems that function correctly on time and within budget.
>
> That it didn't sole all problems oft software development doesn't 
> mean that it isn't a useful aid in strucutring a project.
>
That's true. But it emans that advocates should have considerable
humility. They dn't have all the answers.

[toc] | [prev] | [next] | [standalone]


#157796

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-26 18:50 +0100
Message-ID<rs7t5n$cuc$1@dont-email.me>
In reply to#157794
>> That it didn't sole all problems oft software development doesn't
>> mean that it isn't a useful aid in strucutring a project.

> That's true. But it emans that advocates should have considerable
> humility. They dn't have all the answers.

But programmig without OOP is frustrating for me the larger
a project becomes.

[toc] | [prev] | [next] | [standalone]


#157788

FromTim Rentsch <tr.17687@z991.linuxsc.com>
Date2020-12-26 07:40 -0800
Message-ID<867dp4y3sa.fsf@linuxsc.com>
In reply to#157738
Michael S <already5chosen@yahoo.com> writes:

> 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?

I don't know what he means well enough to say either way.  Both
"object-oriented programming" and "exceptionally bad idea" mean
different things to different people.  As a general rule I don't
want to say either I agree or I don't agree if I don't know what
agreement or disagreement would entail.

[toc] | [prev] | [next] | [standalone]


#157393

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 15:36 +0100
Message-ID<rriepj$c6t$1@dont-email.me>
In reply to#157384
I think that should be the simplest solution:

#include <vector>
#include <filesystem>
#include <limits>
#include <stdexcept>
#include <fstream>

// may throw filesystem_error
// may throw bad_alloc
// may throw ios_base::failure

using namespace std;

vector<char> readFile( char const *pth )
{
     filesystem::path path( pth, pth + strlen( pth ) );
     uintmax_t fileSize = filesystem::file_size( pth );
     if( fileSize + 1 > numeric_limits<size_t>::max() )
         throw bad_alloc();
     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;
}

It's a bit different than the original C-solution since it throws an
I/O-error but that's the more meaningful way to handle this situation.
And note: data is returned implicitly as an rvalue so std::move() isn't
necessary !

[toc] | [prev] | [next] | [standalone]


#157398

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 17:49 +0100
Message-ID<rrimim$731$1@dont-email.me>
In reply to#157393
> vector<char> readFile( char const *pth )
> {
>      filesystem::path path( pth, pth + strlen( pth ) );
>      uintmax_t fileSize = filesystem::file_size( pth );
Oh, I'm using pth and not path here. My compiler should have given
an  error here but my standard-library-implementation also allows
zero-terminated strings fot file_size (just like it also supports
a std:exception constructor with a char * argument, which is also
not standard). So because of this extension I didn't note this
non-conformance.
>      if( fileSize + 1 > numeric_limits<size_t>::max() )
>          throw bad_alloc();
>      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;
> }

[toc] | [prev] | [next] | [standalone]


#157394

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 15:39 +0100
Message-ID<rrievn$d38$1@dont-email.me>
In reply to#157384
>      char[] readFile(char* path) {
>          ...
>          char data[filesize];
>          ...
>          return data;
>      }

LOL, you return a pointer inside the stack.

[toc] | [prev] | [next] | [standalone]


#157396

FromBart <bc@freeuk.com>
Date2020-12-18 16:25 +0000
Message-ID<jK4DH.83556$3Gbc.14930@fx01.ams4>
In reply to#157394
On 18/12/2020 14:39, Bonita Montero wrote:
>>      char[] readFile(char* path) {
>>          ...
>>          char data[filesize];
>>          ...
>>          return data;
>>      }
> 
> LOL, you return a pointer inside the stack.
> 

As I said in my recent post, this is not meant to be a VLA.

This is a similar thing in one of my languages (this is statically typed):

     function readfile(string path)string s =
         s:=path*10
         return s
     end

     proc start=
         println readfile("abc")
     end

It prints abcabcabcabcabcabcabcabcabcabc.

The 'string' type in that function is similar to the char[] type of my 
example. It is not a raw C array type where it just returns a pointer to 
the local array.

[toc] | [prev] | [next] | [standalone]


#157427

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-12-19 01:55 +0300
Message-ID<20201219015524.ceeb81e5ac9ac93837547746@gmail.com>
In reply to#157396
Bart:

> As I said in my recent post, this is not meant to be a
> VLA.

Of course. FreePascal, for example, offers an entirely
managed, reference-counted type of dynamic array that works
like Bart's:

{$mode TP}
{$I-}
Program ReadFileTest;

type TCharArr = array of Char;

function ReadFileAsCharArr( path: String; var data: TCharArr ): Boolean;
var f   : File of Byte;
    size:         Int64;
    open:         Boolean;
begin
    ReadFileAsCharArr := false;
    Assign( f, path );
    open := false;
    while true do
    begin
        Reset( f );
        if IOResult <> 0 then break;

        open := true;
        size := FileSize( f );
        if IOResult <> 0 then break;

        SetLength( data, size );
        BlockRead( f, (@(data[0]))^, size );
        if IOResult <> 0 then break;

        ReadFileAsCharArr := true;
        break;
    end;
    if open then Close( f );
end;

var i, n   : Integer ;
    content: TCharArr; { no explicit management! }
begin
    if ReadFileAsCharArr( 'test.txt', content ) then
    begin
        n     := Length( content );
        for i := 0 to n - 1 do
            Write( content[i] );
        WriteLn();
    end else WriteLn('Fail.');
end.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]


#157428

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 23:58 +0100
Message-ID<rrjc6q$5vt$1@dont-email.me>
In reply to#157427
> Of course. FreePascal, for example, offers an entirely
> managed, reference-counted type of dynamic array that works
> like Bart's:
> 
> {$mode TP}
> {$I-}
> Program ReadFileTest;
> 
> type TCharArr = array of Char;
> 
> function ReadFileAsCharArr( path: String; var data: TCharArr ): Boolean;
> var f   : File of Byte;
>      size:         Int64;
>      open:         Boolean;
> begin
>      ReadFileAsCharArr := false;
>      Assign( f, path );
>      open := false;
>      while true do
>      begin
>          Reset( f );
>          if IOResult <> 0 then break;
> 
>          open := true;
>          size := FileSize( f );
>          if IOResult <> 0 then break;
> 
>          SetLength( data, size );
>          BlockRead( f, (@(data[0]))^, size );
>          if IOResult <> 0 then break;
> 
>          ReadFileAsCharArr := true;
>          break;
>      end;
>      if open then Close( f );
> end;
> 
> var i, n   : Integer ;
>      content: TCharArr; { no explicit management! }
> begin
>      if ReadFileAsCharArr( 'test.txt', content ) then
>      begin
>          n     := Length( content );
>          for i := 0 to n - 1 do
>              Write( content[i] );
>          WriteLn();
>      end else WriteLn('Fail.');
> end.

Doesn't FreePascal support exceptions ?

[toc] | [prev] | [next] | [standalone]


#157458

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-12-19 17:16 +0300
Message-ID<20201219171605.345e6582fc58553bc3187ab3@gmail.com>
In reply to#157428
Bonita Montero to Anton Shepelev:

> > Of course. FreePascal, for example, offers an entirely
> > managed, reference-counted type of dynamic array that
> > works like Bart's:
> >
> > [code with status-based error handling]
>
> Doesn't FreePascal support exceptions ?

Oh yes, and OOP and generics, too. Only I never use them.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]


#157465

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-19 16:05 +0100
Message-ID<rrl4ru$86k$2@dont-email.me>
In reply to#157458
>> Doesn't FreePascal support exceptions ?

> Oh yes, and OOP and generics, too. Only I never use them.

Then you're stupid.

[toc] | [prev] | [next] | [standalone]


#157466

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-12-19 18:33 +0300
Message-ID<20201219183353.b61ddde040ccb24eada54720@gmail.com>
In reply to#157465
Bonita Montero:

> Then you're stupid.

Yours is a funny way to promote C++ in a group about C -- by
insulting C programmers and demeaning the philocophy and
ideology of C, instead of trying to understand them. You are
creating a good repution for C++ programmers and their
language.

Insults are the arguments of the wrong
(Jean-Jacques Rousseau)

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]


#157470

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-19 16:55 +0100
Message-ID<rrl7q8$sjp$1@dont-email.me>
In reply to#157466
> ..., instead of trying to understand them. 

What is there to understand in writing with C ?
C is a rudumentary language with no modern language-facilites.

[toc] | [prev] | [next] | [standalone]


#157412

FromBen Bacarisse <ben.usenet@bsb.me.uk>
Date2020-12-18 19:10 +0000
Message-ID<878s9vylpa.fsf@bsb.me.uk>
In reply to#157394
Bonita Montero <Bonita.Montero@gmail.com> writes:

>>      char[] readFile(char* path) {
>>          ...
>>          char data[filesize];
>>          ...
>>          return data;
>>      }
>
> LOL, you return a pointer inside the stack.

No, Bart was not posting C.  That's clear from the char[] (a syntax
error in C) and from the "try" block you cut.  It was also clear from
the preceding line that you cut:

  "I would expect a 'better' language in the style of C to allow you to
  write it more like this"

-- 
Ben.

[toc] | [prev] | [next] | [standalone]


#157385

FromAnton Shepelev <anton.txt@gmail.com>
Date2020-12-18 16:47 +0300
Message-ID<20201218164725.235b7476f46aef8e43647dec@gmail.com>
In reply to#157377
Bonita Montero to Anton Shepelev:

> > Your code is cluttered with longcompound identifiers.
>
> Doen't matter

Why not?  Reading your code is like wading knee-deep through
molassess over a bottom strewn with stumbling stones.


P.S.: I did not write "longcompound" as a compund word.

-- 
()  ascii ribbon campaign -- against html e-mail
/\  http://preview.tinyurl.com/qcy6mjc [archived]

[toc] | [prev] | [next] | [standalone]


#157390

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 15:22 +0100
Message-ID<rridug$679$1@dont-email.me>
In reply to#157385
>>> Your code is cluttered with longcompound identifiers.

>> Doen't matter

> Why not?  Reading your code is like wading knee-deep through
> molassess over a bottom strewn with stumbling stones.

For someone who isn't familiar with C++ this might look so. But for a
C++-programmer it's much easier to read than C-code. And when you have
really complex code you can put the things together in C++ much more
compact and reliable.
C is a rudimentary language which lacks all modern language-features
and should be only used if there isn't a better language-implementation
available.

[toc] | [prev] | [next] | [standalone]


#157378

FromBonita Montero <Bonita.Montero@gmail.com>
Date2020-12-18 07:09 +0100
Message-ID<rrhh35$ch7$1@dont-email.me>
In reply to#157364
> #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;
> }

Hm, catching the exception is necessary since the code needs
to return the array even with an I/O-error, but setting the
zero-terminator isn't necessary since the whole array is
default-initialized.

[toc] | [prev] | [next] | [standalone]


Page 10 of 15 — ← Prev page 1 … 8 9 [10] 11 12 … 15  Next page →

Back to top | Article view | comp.lang.c


csiph-web