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

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

A defer mechanism for C

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

#157577

Bart to Anton Shepelev:

> > For each object, size calls shall be made to the fgetc()
> > function and the results stored, in the order read, in
> > an array of unsigned char exactly overlaying the object.
>
> When I tried using an fgetc() loop instead of fread(), my
> 800MB test file took 50 seconds to read in instead of 3
> seconds.

I wonder why, considering that fread() is documented as
calling fgetc() internally:

,----[ https://manned.org/fread.3posix ]
| For each object, size calls shall be made to the fgetc()
| function and the results stored, in the order read, in an
| array of unsigned char exactly overlaying the object.
`------------------------------------------------------

Perhaps fread() takes the liberty of behaving as if it were
calling fgetc(), but in fact doing someting else. Is the
performacne difference due to the cost of function calls or
due to buffering and caching?

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

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

#157579

On 21/12/2020 13:25, Anton Shepelev wrote:
> Bart to Anton Shepelev:
> 
>>> For each object, size calls shall be made to the fgetc()
>>> function and the results stored, in the order read, in
>>> an array of unsigned char exactly overlaying the object.
>>
>> When I tried using an fgetc() loop instead of fread(), my
>> 800MB test file took 50 seconds to read in instead of 3
>> seconds.
> 
> I wonder why, considering that fread() is documented as
> calling fgetc() internally:
> 
> ,----[ https://manned.org/fread.3posix ]
> | For each object, size calls shall be made to the fgetc()
> | function and the results stored, in the order read, in an
> | array of unsigned char exactly overlaying the object.
> `------------------------------------------------------
> 
> Perhaps fread() takes the liberty of behaving as if it were
> calling fgetc(), but in fact doing someting else. Is the
> performacne difference due to the cost of function calls or
> due to buffering and caching?
> 

Maybe it relies on fgetc being a macro, or being inlined.

But my test was anyway on Windows where it might work differently. 
Compiling with gcc-O3 didn't help.

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

#157582

On 12/21/20 8:25 AM, Anton Shepelev wrote:
> Bart to Anton Shepelev:
...
>> When I tried using an fgetc() loop instead of fread(), my
>> 800MB test file took 50 seconds to read in instead of 3
>> seconds.
> 
> I wonder why, considering that fread() is documented as
> calling fgetc() internally:
> 
> ,----[ https://manned.org/fread.3posix ]
> | For each object, size calls shall be made to the fgetc()
> | function and the results stored, in the order read, in an
> | array of unsigned char exactly overlaying the object.
> `------------------------------------------------------
> 
> Perhaps fread() takes the liberty of behaving as if it were
> calling fgetc(), but in fact doing someting else. Is the
> performacne difference due to the cost of function calls or
> due to buffering and caching?

The standard only requires that the observable behavior  be the same as
if it called fgetc(). That gives an implementation the freedom to
implement fread() so that it uses an implementation-specific method for
reading in a large piece of the file at one time, which might be faster
than reading a character at a time. If that read failed, it would only
need to adjust the file position marker to the value it would have had
if the file had been read one byte at time. This is why the contents of
the read buffer are unspecified if fread() fails.

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

#157320

David Brown <david.brown@hesbynett.no> writes:

> On 16/12/2020 16:57, Ben Bacarisse wrote:
>> Bart <bc@freeuk.com> writes:
>> 
>>> On 15/12/2020 21:57, Thiago Adams wrote:
>>>> https://gustedt.wordpress.com/2020/12/14/a-defer-mechanism-for-c/
>>>
>>> This the example used:
>>>
>>> guard {
>>>   void * const p = malloc(25);
>>>   if (!p) break;
>>>   defer free(p);
>>>   void * const q = malloc(25);
>>>   if (!q) break;
>>>   defer free(q);
>>>   if (mtx_lock(&mut)==thrd_error) break;
>>>   defer mtx_unlock(&mut);
>>>   // all resources acquired
>>>   // use p, q, and mut until the end of the block
>>>   ...
>>> }
>> 
>> (Just piggybacking because you posted the example.)
>> 
>> I boring old C, I'd write
>> 
>>   void *const p = malloc(25), *const q = malloc(25);
>>   if (mtx_lock(&mut) == thrd_success) {
>>       // use resources...
>>       mtx_unlock(&mut);
>>   }
>>   free(p);
>>   free(q);
>> 
>> and if the second malloc really must be conditional
>> 
>>   void *const p = malloc(25), *const q = p ? malloc(25) : 0;
>> 
>
> and then you'd want :
>
> if (q && (mtx_lock(&mut) == thrd_success)) {

Sure.  In fact, if the const can be dispensed with, I'd usually write it
the way I showed in the "goto" thread:

  if ((p = malloc(25)) &&
      (q = malloc(25)) &&
      mtx_lock(&mut) == thrd_success) {

>> The main cited advantage is the proximity of the defer to the
>> allocation, but the result is inelegant in my option.  I keep thinking
>> there must be better, more compelling examples.
>> 
>
> Basically, it let's you write code in the form:
>
> 	void * const p = malloc(25);
> 	if (!p) return;
>
> 	void * const q = malloc(25);
> 	if (!q) return;
>
> Sometimes it's nicer to write in that way, especially if there are
> different things that can fail at different times, and if you want to
> report the status back to the calling function.

Maybe I don't write enough "real" code these days, but I keep wanting to
see an example where I'd either to use either gotos or some new
construct like this one.  In both threads I'm missing a compelling
example.

-- 
Ben.

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

#157321

>    if ((p = malloc(25)) &&
>        (q = malloc(25)) &&
>        mtx_lock(&mut) == thrd_success) {

Then you would have to set all values before to a zero-state and
check all values afterwards if theire not zero. With this deferrring
or RAII in C++ only the initialized values are going to be destructed.
That's more efficient. And In C++ that's even more convenient as already
initialized sub-objects are desrtructed when the destructor of the outer
object can't complete and throws an exception.

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

#157322

On 2020-12-16, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>>    if ((p = malloc(25)) &&
>>        (q = malloc(25)) &&
>>        mtx_lock(&mut) == thrd_success) {
>
> Then you would have to set all values before to a zero-state and
> check all values afterwards if theire not zero. With this deferrring
> or RAII in C++ only the initialized values are going to be destructed.
> That's more efficient.

That is at best /equally/ efficient, if we can compile the C++ without
any run-time support for exceptions (or any of its associated costs),
such that the scoped "RAII" cleanup is driven only by orinary, statement
terminations; the code doesn't have to be generated to handle
exception-driven unwinding.

-- 
TXR Programming Language: http://nongnu.org/txr

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

#157339

>>>     if ((p = malloc(25)) &&
>>>         (q = malloc(25)) &&
>>>         mtx_lock(&mut) == thrd_success) {

>> Then you would have to set all values before to a zero-state and
>> check all values afterwards if theire not zero. With this deferrring
>> or RAII in C++ only the initialized values are going to be destructed.
>> That's more efficient.

> That is at best /equally/ efficient, if we can compile the C++ without
> any run-time support for exceptions (or any of its associated costs),
> such that the scoped "RAII" cleanup is driven only by orinary, statement
> terminations; the code doesn't have to be generated to handle
> exception-driven unwinding.

The above code is slower than RAII-code in C++.

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

#157404

On 2020-12-17, Bonita Montero <Bonita.Montero@gmail.com> wrote:
>
>>>>     if ((p = malloc(25)) &&
>>>>         (q = malloc(25)) &&
>>>>         mtx_lock(&mut) == thrd_success) {
>
>>> Then you would have to set all values before to a zero-state and
>>> check all values afterwards if theire not zero. With this deferrring
>>> or RAII in C++ only the initialized values are going to be destructed.
>>> That's more efficient.
>
>> That is at best /equally/ efficient, if we can compile the C++ without
>> any run-time support for exceptions (or any of its associated costs),
>> such that the scoped "RAII" cleanup is driven only by orinary, statement
>> terminations; the code doesn't have to be generated to handle
>> exception-driven unwinding.
>
> The above code is slower than RAII-code in C++.

You must be guessing when you say that, because I tried it and found
them to generate identical machine code.

I wrote the C like code in C++ and included it in the same program, to
keep everything in one translation unit.

The complete source is at the end of my post.

A snippet of the disassembly of the final executable shows that the
functions test0 and test1 are absolutely identical, other than having a
different name and address in memory:

00000560 <test0(mtx*)>:
 560:	83 ec 0c             	sub    $0xc,%esp
 563:	8b 44 24 10          	mov    0x10(%esp),%eax
 567:	8b 00                	mov    (%eax),%eax
 569:	85 c0                	test   %eax,%eax
 56b:	78 04                	js     571 <test0(mtx*)+0x11>
 56d:	83 c4 0c             	add    $0xc,%esp
 570:	c3                   	ret    
 571:	e8 7a fe ff ff       	call   3f0 <mtx_unlock(mtx*) [clone .part.1]>
 576:	8d 76 00             	lea    0x0(%esi),%esi
 579:	8d bc 27 00 00 00 00 	lea    0x0(%edi,%eiz,1),%edi

00000580 <test1(mtx*)>:
 580:	83 ec 0c             	sub    $0xc,%esp
 583:	8b 44 24 10          	mov    0x10(%esp),%eax
 587:	8b 00                	mov    (%eax),%eax
 589:	85 c0                	test   %eax,%eax
 58b:	78 04                	js     591 <test1(mtx*)+0x11>
 58d:	83 c4 0c             	add    $0xc,%esp
 590:	c3                   	ret    
 591:	e8 5a fe ff ff       	call   3f0 <mtx_unlock(mtx*) [clone .part.1]>
 596:	8d 76 00             	lea    0x0(%esi),%esi
 599:	8d bc 27 00 00 00 00 	lea    0x0(%edi,%eiz,1),%edi

In this compiler's ABI, there seems to be no run-time overhead for
exception handling at the catch site; the run-time overhead is all on
the unwind side.

For emphasis, here are the sources of just those functions. One uses
manual cleanup, the other simple RAII classes:

void test0(mtx *mut)
{
   void *p = malloc(25), *q = malloc(25);
   if (mtx_lock(mut) != 0) {
       // use resources...
       mtx_unlock(mut);
   }
   free(p);
   free(q);
}


void test1(mtx *mut)
{
  autofree afp(25), afq(25);
  automutex am(mut);

  if (am) {

  }
}

The complee source code follows:


#include <cassert>
#include <cstdlib>

struct mtx {
  int locked;
};

void mtx_init(mtx *m);
int mtx_lock(mtx *m);
void mtx_unlock(mtx *m);

class autofree
{
  void *ptr;
public:
  autofree(size_t size) : ptr(malloc(size)) { }
  operator void *() { return ptr; }
  ~autofree() { free(ptr); }
};

class automutex
{
  mtx *mut;
  int success;
public:
  automutex(mtx *m) : mut(m) { success = mtx_lock(mut); }
  ~automutex() { mtx_unlock(mut); }
  operator bool () { return success != 0; }
};

void test0(mtx *mut)
{
   void *p = malloc(25), *q = malloc(25);
   if (mtx_lock(mut) != 0) {
       // use resources...
       mtx_unlock(mut);
   }
   free(p);
   free(q);
}


void test1(mtx *mut)
{
  autofree afp(25), afq(25);
  automutex am(mut);

  if (am) {
    // Use resources..
  }
}

int main()
{
  mtx m;
  mtx_init(&m);
  test0(&m);
  test1(&m);
}

void mtx_init(mtx *m)
{
  m->locked = 0;
}

int mtx_lock(mtx *m)
{
  m->locked++;
  return 1;
}

void mtx_unlock(mtx *m)
{
  --m->locked;
  assert(m->locked >= 0);
}

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

#157405

The C++ assembly output is by far larger for sure becuase modern
compilers use table-driven exception-handling. But with table
-driven exception-handling has almost no runtime-overhead when
no exception is thrown. But there are a lot of tables which
connect the return-adresses of potential points where exceptions
might go up the call-stack as well as a lot of unwind-code if
exceptions are thrown with help of this tables. But all this
static memory-overhead results in almost no overhead if the
exception isn't thrown.

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

#157409

On 2020-12-18, Bonita Montero <Bonita.Montero@gmail.com> wrote:
> The C++ assembly output is by far larger for sure becuase modern

Larger than what? I have not shown any assembly output that is larger
than some other assembly output. I showed two snippets of assembly
output which show that two functions are identical.

I /think/ you're responding to my post acording to the References
header, though there is no attribution. Are you?

If so, do you have an issue with my method? It is as
apples-versus-apples as I could think of making it.

The exact same language and compiler are used, against the same
translation unit.

The C compatible technique produces identical to the RAII version.

> compilers use table-driven exception-handling. But with table

The C style routine, which has no destructors in it and therefore
does not have to be referenced by any exception handling tables,
translates to exactly the same machine code as the function that calls
constructors and destructors.

This compiler (GNU C++) makes sure you don't pay for exception handling
when you're not throwing an exception, other than in code size.

Though I made some remarks about this, the result I'm presenting has
nothing to do with executable size or exception handling.

You prompted this discussion by claiming that the code with explicit
freeing and mutex manipulation will be slower than RAII.

I have not disproved that claim in general, but I have a clear
counterexample with one popular and relevant C++ compiler.

I strongly suspect that you were just making stuff up when you made
the claim.

-- 
TXR Programming Language: http://nongnu.org/txr

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

#157416

>> The C++ assembly output is by far larger for sure becuase modern

> Larger than what? I have not shown any assembly output that is larger
> than some other assembly output. I showed two snippets of assembly
> output which show that two functions are identical.

I have explained why automatic error-handling through exceptions
results in a larger executable-size than in C and why the perfor-
mance is higher.

> The C style routine, which has no destructors in it and therefore
> does not have to be referenced by any exception handling tables,
> translates to exactly the same machine code as the function that
> calls constructors and destructors.

But error-handling in C is slower because of what I've explained.

> This compiler (GNU C++) makes sure you don't pay for exception handling
> when you're not throwing an exception, other than in code size.

In C++, but not in C.

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

#157429

Bonita Montero:

> But error-handling in C is slower because of what I've
> explained.

Slower by how much, and in what programs does it make a
noticeable and significant difference to worry about?

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

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

#157431

>> But error-handling in C is slower because of what I've
>> explained.

> Slower by how much, and in what programs does it make a
> noticeable and significant difference to worry about?

In performance-relevant programs wich a high frequency of allocations
on the heap. F.e. DB-servers which allocate a block for each column
and a series of blocks for each row. In such cases the overhead is
almost zero in C++.

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

#157454

Bonita Montero to Anton Shepelev:

> > Bonita Montero:
> >
> > > But error-handling in C is slower because of what I've
> > > explained.
> >
> > Slower by how much, and in what programs does it make a
> > noticeable and significant difference to worry about?
>
> In performance-relevant programs wich a high frequency of
> allocations on the heap. F.e. DB-servers which allocate a
> block for each column and a series of blocks for each row.
> In such cases the overhead is almost zero in C++.

That is a good example, but since I am not disposed to agree
with you easily, I will need I profiler trace that
demonstrates that the C overhead is significant. If it is 5%
I won't care and call exceptions not worth it.  Futhermore,
I see that Kaz Kylheku, obviously a more knowledgeable
fellow than I, has found out that in a practical example C++
has shown no difference from C whatsoever!

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

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

#157457

On Saturday, December 19, 2020 at 10:52:08 AM UTC-3, Anton Shepelev wrote:
> Bonita Montero to Anton Shepelev: 
> 
> > > Bonita Montero:
> > > 
> > > > But error-handling in C is slower because of what I've 
> > > > explained. 
> > > 
> > > Slower by how much, and in what programs does it make a 
> > > noticeable and significant difference to worry about? 
> > 
> > In performance-relevant programs wich a high frequency of 
> > allocations on the heap. F.e. DB-servers which allocate a 
> > block for each column and a series of blocks for each row. 
> > In such cases the overhead is almost zero in C++.
> That is a good example, but since I am not disposed to agree 
> with you easily, I will need I profiler trace that 
> demonstrates that the C overhead is significant. If it is 5% 
> I won't care and call exceptions not worth it. Futhermore, 
> I see that Kaz Kylheku, obviously a more knowledgeable 
> fellow than I, has found out that in a practical example C++ 
> has shown no difference from C whatsoever!


I my experience C is always faster than C++.

Something that needs to be considered is that
direct C code is easier to optimized compared with
deep nested C++ code with exceptions.

if you don t have (in theory) overhead with the good path
in C++ exceptions, in practice the generated code can
(and generally it is) less efficient.

C++ compilers do miracles with inline.. and this saves
the programmer in many ways. But when this doesn't work
so well the problem is hidden (unless you check your code
constantly)

Comparing any other language performance with C, is 
just a matter how far you are from the ideal code.

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

#157459

On Saturday, 19 December 2020 at 14:16:06 UTC, Thiago Adams wrote:
> On Saturday, December 19, 2020 at 10:52:08 AM UTC-3, Anton Shepelev wrote: 
> > Bonita Montero to Anton Shepelev: 
> > 
> > > > Bonita Montero: 
> > > > 
> > > > > But error-handling in C is slower because of what I've 
> > > > > explained. 
> > > > 
> > > > Slower by how much, and in what programs does it make a 
> > > > noticeable and significant difference to worry about? 
> > > 
> > > In performance-relevant programs wich a high frequency of 
> > > allocations on the heap. F.e. DB-servers which allocate a 
> > > block for each column and a series of blocks for each row. 
> > > In such cases the overhead is almost zero in C++. 
> > That is a good example, but since I am not disposed to agree 
> > with you easily, I will need I profiler trace that 
> > demonstrates that the C overhead is significant. If it is 5% 
> > I won't care and call exceptions not worth it. Futhermore, 
> > I see that Kaz Kylheku, obviously a more knowledgeable 
> > fellow than I, has found out that in a practical example C++ 
> > has shown no difference from C whatsoever!
> I my experience C is always faster than C++. 
> 
> Comparing any other language performance with C, is 
> just a matter how far you are from the ideal code.
>
One advantage of C++ is that data structures like balanced binary
trees  come as standard. These are hard to implement in C, and
harder still to implement really efficiently. 

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

#157463

>> Comparing any other language performance with C, is
>> just a matter how far you are from the ideal code.

> One advantage of C++ is that data structures like balanced binary
> trees come as standard. ...

Implementing binary trees isn't difficult, but just some hours of work.
But what I don't understand is why the standard-libraries always chose
a red-black-tree over AVL-trees; red-black-trees have mostly a lower
overhead when inserting and are faster if there about an equal number
of inserts like lookups, but lookups themselves are almost every time
faster in an AVL-tree because red-black-trees are not balanced so good
and become deeper.

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

#157468

Malcolm McLean:

> One advantage of C++ is that data structures like balanced
> binary trees  come as standard. These are hard to
> implement in C, and harder still to implement really
> efficiently.

That is not the advantage of a language, but the result of
its bloat: include everything into the standard library. I
think balanced trees are hard to implement regardless of
language, which is a good protection against abuse. You
implement them only when you have exhausted all the simpler
alternatives. Or you can use an existing implementation.

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

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

#157471

> That is not the advantage of a language, but the result of
> its bloat: include everything into the standard library.

But very fast bloat.

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

#157462

> I my experience C is always faster than C++.

If you program idiomatically in C++ that's true, but if not you're
equally fast. But sometimes you're faster. F.e. you don't specialize
a qsort() for every data-type whereas in C++ templates do this.

> Something that needs to be considered is that
> direct C code is easier to optimized compared with
> deep nested C++ code with exceptions.

C++-exceptions lead to an error-handling that has an almost zero runtime
-overhead if no exception is thrown; and that's the performace-relevant
case.

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

Page 13 of 15 — ← Prev page 1 … 11 12 [13] 14 15  Next page →

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

csiph-web