Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c++ > #120154 > unrolled thread
| Started by | jseigh <jseigh_es00@xemaps.com> |
|---|---|
| First post | 2024-09-21 15:43 -0400 |
| Last post | 2024-09-25 15:23 -0400 |
| Articles | 20 on this page of 258 — 15 participants |
Back to article view | Back to comp.lang.c++
C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-21 15:43 -0400
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-22 08:06 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 10:45 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-22 08:59 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 11:03 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-22 09:08 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 11:51 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-22 15:15 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 17:33 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 07:39 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 10:54 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 09:32 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 11:45 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 13:56 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 16:00 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 14:03 +0000
Re: C++ named requirements as concepts scott@slp53.sl.home (Scott Lurndal) - 2024-09-23 15:48 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 17:52 +0200
Re: C++ named requirements as concepts scott@slp53.sl.home (Scott Lurndal) - 2024-09-23 15:47 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 17:53 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 07:20 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 09:33 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 08:11 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 11:17 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 11:46 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 10:52 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 12:54 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 10:59 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 13:05 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 11:07 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 13:21 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 13:51 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 15:56 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 15:43 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 17:48 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 07:19 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 11:30 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 09:49 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 08:24 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 11:32 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 11:15 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 13:30 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 12:43 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 14:50 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:00 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 12:47 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 15:00 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 13:22 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 17:12 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 15:35 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 19:19 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 07:36 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 11:36 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 13:11 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 13:31 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-09-25 13:52 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 14:06 +0300
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:22 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 11:12 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 14:30 +0300
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:34 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 14:38 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 15:01 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 12:40 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 13:23 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 13:33 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 14:38 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 13:45 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:36 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 14:39 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 15:04 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 17:14 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 16:23 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 17:18 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 17:26 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 17:14 +0200
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-09-25 21:24 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 20:37 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 13:49 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 14:03 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:38 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 15:17 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-09-25 15:49 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 14:52 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 12:55 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 15:08 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 13:24 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 15:28 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 13:36 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 15:44 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 14:11 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 16:14 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 15:32 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 17:33 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 15:49 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 17:53 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 07:34 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 10:20 +0200
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-26 16:46 +0800
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-26 16:51 +0800
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 11:20 +0200
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-26 19:17 +0800
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-26 19:27 +0800
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 13:32 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-26 12:23 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 11:25 +0200
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-26 19:20 +0800
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 10:03 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 13:33 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 14:09 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 16:14 +0200
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-27 02:27 -0700
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-27 11:11 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-27 16:14 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-27 15:25 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-27 18:24 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-28 09:12 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-28 17:33 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-28 15:47 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-29 13:41 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-29 13:48 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-29 14:49 +0300
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-29 11:23 -0700
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.com - 2024-09-30 07:26 +0000
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-09-30 07:40 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-30 12:24 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-09-30 15:47 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-30 17:58 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-30 10:57 +0200
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-30 05:29 -0700
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-30 14:34 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-30 15:21 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-09-30 16:00 +0000
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-09-30 16:09 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-30 19:43 +0300
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 07:31 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-01 11:01 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 10:06 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 09:58 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 12:58 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 16:14 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 19:43 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-02 07:11 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-02 09:34 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 09:57 +0000
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-30 10:18 -0700
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 07:32 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-30 19:51 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 07:36 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 10:00 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-10-01 10:42 +0200
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-01 12:53 +0300
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 10:02 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-01 13:11 +0300
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 16:13 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-01 21:50 +0300
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-01 20:06 -0700
Re: C++ named requirements as concepts User <noreply@user.com> - 2024-10-02 05:47 +0100
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-04 06:52 -0700
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-04 13:57 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-02 13:02 +0300
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-04 06:57 -0700
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-06 14:19 +0300
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-10-06 14:22 +0200
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-07 09:11 -0700
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-07 22:53 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-08 18:11 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-08 22:48 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-09 00:12 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-09 01:06 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-09 08:25 +0300
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-09 08:28 +0200
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-09 10:26 +0300
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-09 09:31 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-09 13:58 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-09 14:39 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-09 19:59 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-10-09 22:37 +0300
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-10 11:47 +0300
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-11 04:58 -0700
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-10-11 16:03 +0300
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-12 07:41 -0700
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-12 08:18 -0700
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-10-11 03:57 -0700
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-07 19:19 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-02 07:13 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-10-01 13:06 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 10:01 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-10-01 13:08 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 16:15 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 19:44 +0200
Re: C++ named requirements as concepts Muttley@DastartdlyHQ.org - 2024-10-01 09:56 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-01 13:01 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-29 15:00 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-29 14:37 +0300
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-29 15:42 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-29 15:47 +0200
Re: C++ named requirements as concepts Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-09-28 04:28 -0700
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-28 13:55 +0000
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 15:33 +0000
Re: C++ named requirements as concepts Michael S <already5chosen@yahoo.com> - 2024-09-25 17:16 +0300
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-09-25 16:22 +0300
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-25 13:34 +0000
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 17:27 +0200
Re: C++ named requirements as concepts Paavo Helde <eesnimi@osa.pri.ee> - 2024-09-25 22:37 +0300
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 07:38 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 10:21 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 10:03 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 13:29 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-26 14:09 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-26 16:17 +0200
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 15:07 +0200
Re: C++ named requirements as concepts Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-26 18:22 -0700
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-25 14:58 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-25 15:19 +0200
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-24 13:55 -0700
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 10:50 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 12:53 +0200
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-22 07:58 -0400
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 14:10 +0200
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-23 11:08 -0400
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 17:21 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-22 15:21 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 17:34 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 07:40 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 10:55 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 09:33 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 11:46 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 13:59 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 16:02 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-23 14:05 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 16:10 +0200
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-23 12:55 -0700
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-23 16:24 -0400
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-23 14:43 -0700
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-23 18:59 -0400
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-23 16:06 -0700
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-23 16:10 -0700
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-24 09:15 -0400
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 07:23 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 09:34 +0200
Re: C++ named requirements as concepts Muttley@dastardlyhq.com - 2024-09-24 08:14 +0000
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 11:18 +0200
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-24 08:59 -0400
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 15:02 +0200
Re: C++ named requirements as concepts "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2024-09-24 13:37 -0700
Re: C++ named requirements as concepts Jack <noreply@mandrill.com> - 2024-09-23 00:15 +0000
Re: C++ named requirements as concepts wij <wyniijj5@gmail.com> - 2024-09-23 08:48 +0800
Re: C++ named requirements as concepts David Brown <david.brown@hesbynett.no> - 2024-09-22 11:46 +0200
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-22 13:35 +0200
Re: C++ named requirements as concepts Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-22 11:43 -0700
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-22 17:00 -0400
Re: C++ named requirements as concepts Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-22 14:50 -0700
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-23 10:32 -0400
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-23 16:55 +0200
Re: C++ named requirements as concepts Andrey Tarasevich <andreytarasevich@hotmail.com> - 2024-09-23 08:11 -0700
Re: C++ named requirements as concepts Bonita Montero <Bonita.Montero@gmail.com> - 2024-09-24 08:24 +0200
Re: C++ named requirements as concepts jseigh <jseigh_es00@xemaps.com> - 2024-09-25 15:23 -0400
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-02 13:02 +0300 |
| Message-ID | <20241002130236.000005e0@yahoo.com> |
| In reply to | #120535 |
On Tue, 01 Oct 2024 20:06:20 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > And best (for me, personally, YMMV) solution in pure functional > > languges is to avoid programming in such languages. > > What do you count as a pure functional language? C++ templates sub-languges. I.e. approximately compile-time part of C++ taken in isolation from run-time part and without C++11 and later additions.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-04 06:57 -0700 |
| Message-ID | <8634lc0y43.fsf@linuxsc.com> |
| In reply to | #120543 |
Michael S <already5chosen@yahoo.com> writes: > On Tue, 01 Oct 2024 20:06:20 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> And best (for me, personally, YMMV) solution in pure functional >>> languges is to avoid programming in such languages. >> >> What do you count as a pure functional language? > > C++ templates sub-languges. I.e. approximately compile-time part of > C++ taken in isolation from run-time part and without C++11 and later > additions. If that's your only example then not very much is excluded. It's like saying you don't want to program Turing Machines. Are there any mainstream languages you would count as purely functional? (I think it's fair to say that the C++ template sub-language is not a mainstream language.)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-06 14:19 +0300 |
| Message-ID | <20241006141907.00005a57@yahoo.com> |
| In reply to | #120558 |
On Fri, 04 Oct 2024 06:57:32 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Tue, 01 Oct 2024 20:06:20 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> And best (for me, personally, YMMV) solution in pure functional > >>> languges is to avoid programming in such languages. > >> > >> What do you count as a pure functional language? > > > > C++ templates sub-languges. I.e. approximately compile-time part of > > C++ taken in isolation from run-time part and without C++11 and > > later additions. > > If that's your only example then not very much is excluded. Since I don't like functional programming it seems to me rather natural that I am positioned as far as it goes from being an expert in the field. So far I found only one field of computer programming that I like even less - regular expressions. > It's like saying you don't want to program Turing Machines. > Are there any mainstream languages you would count as purely > functional? (I think it's fair to say that the C++ template > sub-language is not a mainstream language.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-06 14:22 +0200 |
| Message-ID | <vdtven$17qvk$1@dont-email.me> |
| In reply to | #120603 |
On 06/10/2024 13:19, Michael S wrote: > On Fri, 04 Oct 2024 06:57:32 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Tue, 01 Oct 2024 20:06:20 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> And best (for me, personally, YMMV) solution in pure functional >>>>> languges is to avoid programming in such languages. >>>> >>>> What do you count as a pure functional language? >>> >>> C++ templates sub-languges. I.e. approximately compile-time part of >>> C++ taken in isolation from run-time part and without C++11 and >>> later additions. >> >> If that's your only example then not very much is excluded. > > Since I don't like functional programming it seems to me rather natural > that I am positioned as far as it goes from being an expert in the > field. > Perhaps it would help if you describe what the term "functional programming" means to you. We could look at particular aspects or features that are commonly considered relevant to functional programming, and think about whether there are some things you like and others that you find distasteful for some reason. (I am not trying to persuade you to switch to Haskell or to change your opinions, but perhaps you'll get a better understanding why some people like functional programming, and others will get a better understanding of why some people dislike it.)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-07 09:11 -0700 |
| Message-ID | <86iku3zydq.fsf@linuxsc.com> |
| In reply to | #120603 |
Michael S <already5chosen@yahoo.com> writes: > On Fri, 04 Oct 2024 06:57:32 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> Michael S <already5chosen@yahoo.com> writes: >> >>> On Tue, 01 Oct 2024 20:06:20 -0700 >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: >>> >>>> Michael S <already5chosen@yahoo.com> writes: >>>> >>>>> And best (for me, personally, YMMV) solution in pure functional >>>>> languges is to avoid programming in such languages. >>>> >>>> What do you count as a pure functional language? >>> >>> C++ templates sub-languges. I.e. approximately compile-time part of >>> C++ taken in isolation from run-time part and without C++11 and >>> later additions. >> >> If that's your only example then not very much is excluded. > > Since I don't like functional programming it seems to me rather > natural that I am positioned as far as it goes from being an > expert in the field. Sorry, I think my comment came across wrongly. The point of my question is not to criticize your reactions but to understand just what things you are reacting to. Different people have different ideas of what "functional programming" means. What language qualities make a language one you would rather avoid? Or conversely, what attributes tend to make a language attractive or one that you would prefer? > So far I found only one field of computer programming that I like > even less - regular expressions. I admit to being puzzled by this reaction. Regular expressions tend not to be very useful outside of a rather narrow niche, but inside their domain of application they are pretty handy. Are you saying that you would rather not use regular expressions even in situations where they are convenient? Or is it that you don't find such cases coming up in your regular programming activities?
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-07 22:53 +0300 |
| Message-ID | <20241007225315.00006d81@yahoo.com> |
| In reply to | #120623 |
On Mon, 07 Oct 2024 09:11:29 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > Michael S <already5chosen@yahoo.com> writes: > > > On Fri, 04 Oct 2024 06:57:32 -0700 > > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > > > >> Michael S <already5chosen@yahoo.com> writes: > >> > >>> On Tue, 01 Oct 2024 20:06:20 -0700 > >>> Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >>> > >>>> Michael S <already5chosen@yahoo.com> writes: > >>>> > >>>>> And best (for me, personally, YMMV) solution in pure functional > >>>>> languges is to avoid programming in such languages. > >>>> > >>>> What do you count as a pure functional language? > >>> > >>> C++ templates sub-languges. I.e. approximately compile-time part > >>> of C++ taken in isolation from run-time part and without C++11 and > >>> later additions. > >> > >> If that's your only example then not very much is excluded. > > > > Since I don't like functional programming it seems to me rather > > natural that I am positioned as far as it goes from being an > > expert in the field. > > Sorry, I think my comment came across wrongly. The point of my > question is not to criticize your reactions but to understand > just what things you are reacting to. Different people have > different ideas of what "functional programming" means. What > language qualities make a language one you would rather avoid? Since we are in C++ group, let's take examples from C++. I never use std::for_each(). I don't use lambda expressions as argument for 'compare' parameter in std::sort or std::nth_element. If it was possible, I wouldn't use object of class with operator() for such parameter either. Instead I would prefer pointer to normal named member function. May be, it is possible, but I don't know the syntax. I hate functional stuff pushed down my throat by <random> and would very much prefer the same very useful functionality provided in other way. > Or conversely, what attributes tend to make a language attractive > or one that you would prefer? > I prefer to see sequence of steps. Or, at least to have some idea about it in 'as if' fashion. > > So far I found only one field of computer programming that I like > > even less - regular expressions. > > I admit to being puzzled by this reaction. Regular expressions tend > not to be very useful outside of a rather narrow niche, but inside > their domain of application they are pretty handy. Are you saying > that you would rather not use regular expressions even in situations > where they are convenient? Yes, if I could, I wouldn't use regular expressions at all. But CAD tools for FPGA development are build in such ways that sometimes regular expressions are necessary to achieve my objectives. The result is that not very often, but far more often than I would like, results do not match expectations. And when it happens, it is *always* very hard to find a reason. > Or is it that you don't find such cases > coming up in your regular programming activities?
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-08 18:11 +0300 |
| Message-ID | <ve3i3c$27d8p$1@dont-email.me> |
| In reply to | #120626 |
On 07.10.2024 22:53, Michael S wrote:
> I don't use lambda expressions as argument for 'compare' parameter in
> std::sort or std::nth_element. If it was possible, I wouldn't use
> object of class with operator() for such parameter either. Instead I
> would prefer pointer to normal named member function.
>
> I prefer to see sequence of steps. Or, at least to have some idea about
> it in 'as if' fashion.
You can easily use a normal named member function for comparison, you
just need a small lambda for calling it.
#include <vector>
#include <algorithm>
#include <iostream>
class A {
public:
int key_;
int type_;
bool MyLess(const A& other) const {
return key_ < other.key_ || (key_ == other.key_ && type_ < other.type_);
}
};
int main() {
std::vector<A> vv{ {12, 50}, {13,12}, {3,7}, {12, 49} };
std::sort(vv.begin(), vv.end(), [](const A& x, const A& y) {return
x.MyLess(y); });
for (A& ref : vv) {
std::cout << ref.key_ << " " << ref.type_ << "\n";
}
}
I like lambda because here I "see the sequence of steps". The earlier
std::bind1st et al were horrific, never used them. Lambda is much better.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-08 22:48 +0300 |
| Message-ID | <20241008224816.00004f1d@yahoo.com> |
| In reply to | #120642 |
On Tue, 8 Oct 2024 18:11:40 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
> On 07.10.2024 22:53, Michael S wrote:
> > I don't use lambda expressions as argument for 'compare' parameter
> > in std::sort or std::nth_element. If it was possible, I wouldn't use
> > object of class with operator() for such parameter either. Instead I
> > would prefer pointer to normal named member function.
> >
> > I prefer to see sequence of steps. Or, at least to have some idea
> > about it in 'as if' fashion.
>
> You can easily use a normal named member function for comparison, you
> just need a small lambda for calling it.
>
> #include <vector>
> #include <algorithm>
> #include <iostream>
>
> class A {
> public:
> int key_;
> int type_;
>
> bool MyLess(const A& other) const {
> return key_ < other.key_ || (key_ == other.key_ &&
> type_ < other.type_); }
> };
>
>
> int main() {
> std::vector<A> vv{ {12, 50}, {13,12}, {3,7}, {12, 49} };
> std::sort(vv.begin(), vv.end(), [](const A& x, const A& y)
> {return x.MyLess(y); });
> for (A& ref : vv) {
> std::cout << ref.key_ << " " << ref.type_ << "\n";
> }
> }
>
> I like lambda because here I "see the sequence of steps". The earlier
> std::bind1st et al were horrific, never used them. Lambda is much
> better.
You has shown an easy case of context free comparison and how to avoid
operator<() in this easy case.
I was talking about less trivial case of context-aware comparison and
about my desire to avoid operator().
Much better(IMHO) solution for your simple case was available since day
one of STL:
#include <algorithm>
#include <cstdio>
class A {
public:
int key_;
int type_;
static inline bool MyLess(const A& a, const A& b) {
return a.key_ < b.key_ || (a.key_ == b.key_ && a.type_
< b.type_); }
};
int main() {
A vv[] = { {12, 50}, {13,12}, {3,7}, {12, 49} };
std::sort(&vv[0], &vv[4], A::MyLess);
for (int i = 0; i < 4; ++i)
printf("%d %d\n", vv[i].key_, vv[i].type_);
}
Here is an example of more interesting sort that demonstrates what I was
talking about and where I would like to use bwt_cmp_t::less directly
instead of via operator():
#include <cstdint>
#include <cstring>
#include <algorithm>
// BWT sort - sort in lexicographic order with circular shift
void bwt_sort(int* dst, const uint8_t* src, int srclen)
{
for (int i = 0; i < srclen; ++i)
dst[i] = i;
struct bwt_cmp_t {
const uint8_t* src;
int srclen;
bool less(int a, int b) const {
if (a >= b) {
if (a > b)
return !less(b, a);
return false; // a == b
}
// a < b;
int diff = memcmp(&src[a], &src[b], srclen-b);
if (diff == 0) {
diff = memcmp(&src[a+srclen-b], &src[0], b-a);
if (diff == 0) {
diff = memcmp(&src[0], &src[b-a], a);
if (diff == 0)
return true; // stable sort
}
}
return diff < 0;
}
bool operator() (int a, int b) const {
return less(a, b);
}
} cmp;
cmp.src = src;
cmp.srclen = srclen;
std::sort(dst, dst+srclen, cmp);
}
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-09 00:12 +0300 |
| Message-ID | <ve477p$2ajn8$1@dont-email.me> |
| In reply to | #120646 |
On 08.10.2024 22:48, Michael S wrote:
> On Tue, 8 Oct 2024 18:11:40 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
>> On 07.10.2024 22:53, Michael S wrote:
>>> I don't use lambda expressions as argument for 'compare' parameter
>>> in std::sort or std::nth_element. If it was possible, I wouldn't use
>>> object of class with operator() for such parameter either. Instead I
>>> would prefer pointer to normal named member function.
>>>
>>> I prefer to see sequence of steps. Or, at least to have some idea
>>> about it in 'as if' fashion.
>>
>> You can easily use a normal named member function for comparison, you
>> just need a small lambda for calling it.
>>
>> #include <vector>
>> #include <algorithm>
>> #include <iostream>
>>
>> class A {
>> public:
>> int key_;
>> int type_;
>>
>> bool MyLess(const A& other) const {
>> return key_ < other.key_ || (key_ == other.key_ &&
>> type_ < other.type_); }
>> };
>>
>>
>> int main() {
>> std::vector<A> vv{ {12, 50}, {13,12}, {3,7}, {12, 49} };
>> std::sort(vv.begin(), vv.end(), [](const A& x, const A& y)
>> {return x.MyLess(y); });
>> for (A& ref : vv) {
>> std::cout << ref.key_ << " " << ref.type_ << "\n";
>> }
>> }
>>
>> I like lambda because here I "see the sequence of steps". The earlier
>> std::bind1st et al were horrific, never used them. Lambda is much
>> better.
>
>
> You has shown an easy case of context free comparison and how to avoid
> operator<() in this easy case.
> I was talking about less trivial case of context-aware comparison and
> about my desire to avoid operator().
>
> Much better(IMHO) solution for your simple case was available since day
> one of STL:
>
> #include <algorithm>
> #include <cstdio>
>
> class A {
> public:
> int key_;
> int type_;
>
> static inline bool MyLess(const A& a, const A& b) {
> return a.key_ < b.key_ || (a.key_ == b.key_ && a.type_
> < b.type_); }
> };
>
>
> int main() {
> A vv[] = { {12, 50}, {13,12}, {3,7}, {12, 49} };
> std::sort(&vv[0], &vv[4], A::MyLess);
> for (int i = 0; i < 4; ++i)
> printf("%d %d\n", vv[i].key_, vv[i].type_);
> }
>
>
>
>
> Here is an example of more interesting sort that demonstrates what I was
> talking about and where I would like to use bwt_cmp_t::less directly
> instead of via operator():
>
> #include <cstdint>
> #include <cstring>
> #include <algorithm>
>
> // BWT sort - sort in lexicographic order with circular shift
> void bwt_sort(int* dst, const uint8_t* src, int srclen)
> {
> for (int i = 0; i < srclen; ++i)
> dst[i] = i;
>
> struct bwt_cmp_t {
> const uint8_t* src;
> int srclen;
> bool less(int a, int b) const {
> if (a >= b) {
> if (a > b)
> return !less(b, a);
> return false; // a == b
> }
> // a < b;
> int diff = memcmp(&src[a], &src[b], srclen-b);
> if (diff == 0) {
> diff = memcmp(&src[a+srclen-b], &src[0], b-a);
> if (diff == 0) {
> diff = memcmp(&src[0], &src[b-a], a);
> if (diff == 0)
> return true; // stable sort
> }
> }
> return diff < 0;
> }
> bool operator() (int a, int b) const {
> return less(a, b);
> }
> } cmp;
> cmp.src = src;
> cmp.srclen = srclen;
> std::sort(dst, dst+srclen, cmp);
> }
>
The context state is the bread and butter of lambda. If all you want is
to avoid operator(), this can be done easily:
// BWT sort - sort in lexicographic order with circular shift
void bwt_sort(int* dst, const uint8_t* src, int srclen) {
for (int i = 0; i < srclen; ++i)
dst[i] = i;
struct bwt_cmp_t {
const uint8_t* src;
int srclen;
bool less(int a, int b) const {
if (a >= b) {
if (a > b)
return !less(b, a);
return false; // a == b
}
// a < b;
int diff = memcmp(&src[a], &src[b], srclen - b);
if (diff == 0) {
diff = memcmp(&src[a + srclen - b], &src[0], b - a);
if (diff == 0) {
diff = memcmp(&src[0], &src[b - a], a);
if (diff == 0)
return true; // stable sort
}
}
return diff < 0;
}
} cmp;
cmp.src = src;
cmp.srclen = srclen;
std::sort(dst, dst + srclen, [&cmp](int a, int b) {return
cmp.less(a, b); });
}
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-09 01:06 +0300 |
| Message-ID | <20241009010605.00001699@yahoo.com> |
| In reply to | #120648 |
On Wed, 9 Oct 2024 00:12:25 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: > > The context state is the bread and butter of lambda. If all you want > is to avoid operator(), this can be done easily: > I want neither operator() nor lambda. I want a way to feed std::sort with honest old [pointer to] object + [pointer to] its honest old member function. And I am not obsessed with idea that it has to be a single prameter at all cost; I see nothing wrong if two separate parameters needed to do the job.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-09 08:25 +0300 |
| Message-ID | <ve5440$2ho2a$1@dont-email.me> |
| In reply to | #120651 |
On 09.10.2024 01:06, Michael S wrote:
> On Wed, 9 Oct 2024 00:12:25 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
>
>>
>> The context state is the bread and butter of lambda. If all you want
>> is to avoid operator(), this can be done easily:
>>
>
> I want neither operator() nor lambda.
> I want a way to feed std::sort with honest old [pointer to] object +
> [pointer to] its honest old member function. And I am not obsessed
> with idea that it has to be a single prameter at all cost; I see nothing
> wrong if two separate parameters needed to do the job.
>
Not quite sure why you might want this, but here it goes:
// Ugly lambda hidden in a common header
namespace std2 {
template<class ELEM, class COMP>
void sort(ELEM* begin, ELEM* end, const COMP& comp, bool (COMP::*
member)(ELEM, ELEM) const) {
std::sort(begin, end, [&comp, member](const ELEM& a, const
ELEM& b) {return (comp.*member)(a, b); });
}
}
// BWT sort - sort in lexicographic order with circular shift
void bwt_sort(int* dst, const uint8_t* src, int srclen) {
for (int i = 0; i < srclen; ++i)
dst[i] = i;
struct bwt_cmp_t {
const uint8_t* src;
int srclen;
bool less(int a, int b) const {
if (a >= b) {
if (a > b)
return !less(b, a);
return false; // a == b
}
// a < b;
int diff = memcmp(&src[a], &src[b], srclen - b);
if (diff == 0) {
diff = memcmp(&src[a + srclen - b], &src[0], b - a);
if (diff == 0) {
diff = memcmp(&src[0], &src[b - a], a);
if (diff == 0)
return true; // stable sort
}
}
return diff < 0;
}
} cmp;
cmp.src = src;
cmp.srclen = srclen;
// Usage without lambda as desired
std2::sort(dst, dst + srclen, cmp, &bwt_cmp_t::less);
}
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-10-09 08:28 +0200 |
| Message-ID | <ve57q0$2ifep$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120653 |
Am 09.10.2024 um 07:25 schrieb Paavo Helde:
> Not quite sure why you might want this, but here it goes:
>
> // Ugly lambda hidden in a common header
> namespace std2 {
> template<class ELEM, class COMP>
> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool (COMP::*
> member)(ELEM, ELEM) const) {
> std::sort(begin, end, [&comp, member](const ELEM& a, const
> ELEM& b) {return (comp.*member)(a, b); });
> }
> }
Use iterators !
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-09 10:26 +0300 |
| Message-ID | <ve5b77$2ism2$1@dont-email.me> |
| In reply to | #120655 |
On 09.10.2024 09:28, Bonita Montero wrote:
> Am 09.10.2024 um 07:25 schrieb Paavo Helde:
>
>> Not quite sure why you might want this, but here it goes:
>>
>> // Ugly lambda hidden in a common header
>> namespace std2 {
>> template<class ELEM, class COMP>
>> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool (COMP::*
>> member)(ELEM, ELEM) const) {
>> std::sort(begin, end, [&comp, member](const ELEM& a, const
>> ELEM& b) {return (comp.*member)(a, b); });
>> }
>> }
>
> Use iterators !
Iterators, concepts and any needed type deduction is left as an exercise
for the reader ;-)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-10-09 09:31 +0000 |
| Message-ID | <ve5iib$2jr06$1@dont-email.me> |
| In reply to | #120661 |
On Wed, 9 Oct 2024 10:26:31 +0300
Paavo Helde <eesnimi@osa.pri.ee> boring babbled:
>On 09.10.2024 09:28, Bonita Montero wrote:
>> Am 09.10.2024 um 07:25 schrieb Paavo Helde:
>>
>>> Not quite sure why you might want this, but here it goes:
>>>
>>> // Ugly lambda hidden in a common header
>>> namespace std2 {
>>> template<class ELEM, class COMP>
>>> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool (COMP::*
>>> member)(ELEM, ELEM) const) {
>>> std::sort(begin, end, [&comp, member](const ELEM& a, const
>
>>> ELEM& b) {return (comp.*member)(a, b); });
>>> }
>>> }
>>
>> Use iterators !
>
>Iterators, concepts and any needed type deduction is left as an exercise
>for the reader ;-)
A C-style function pointer to a member function - been a while since I've
seen one of them!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-09 13:58 +0300 |
| Message-ID | <20241009135825.00002db8@yahoo.com> |
| In reply to | #120653 |
On Wed, 9 Oct 2024 08:25:20 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
> On 09.10.2024 01:06, Michael S wrote:
> > On Wed, 9 Oct 2024 00:12:25 +0300
> > Paavo Helde <eesnimi@osa.pri.ee> wrote:
> >
> >
> >>
> >> The context state is the bread and butter of lambda. If all you
> >> want is to avoid operator(), this can be done easily:
> >>
> >
> > I want neither operator() nor lambda.
> > I want a way to feed std::sort with honest old [pointer to] object +
> > [pointer to] its honest old member function. And I am not obsessed
> > with idea that it has to be a single prameter at all cost; I see
> > nothing wrong if two separate parameters needed to do the job.
> >
>
> Not quite sure why you might want this, but here it goes:
>
> // Ugly lambda hidden in a common header
> namespace std2 {
> template<class ELEM, class COMP>
> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool
> (COMP::* member)(ELEM, ELEM) const) {
> std::sort(begin, end, [&comp, member](const ELEM& a, const
> ELEM& b) {return (comp.*member)(a, b); });
> }
> }
>
> // BWT sort - sort in lexicographic order with circular shift
> void bwt_sort(int* dst, const uint8_t* src, int srclen) {
> for (int i = 0; i < srclen; ++i)
> dst[i] = i;
>
> struct bwt_cmp_t {
> const uint8_t* src;
> int srclen;
> bool less(int a, int b) const {
> if (a >= b) {
> if (a > b)
> return !less(b, a);
> return false; // a == b
> }
> // a < b;
> int diff = memcmp(&src[a], &src[b], srclen - b);
> if (diff == 0) {
> diff = memcmp(&src[a + srclen - b], &src[0], b - a);
> if (diff == 0) {
> diff = memcmp(&src[0], &src[b - a], a);
> if (diff == 0)
> return true; // stable sort
> }
> }
> return diff < 0;
> }
> } cmp;
> cmp.src = src;
> cmp.srclen = srclen;
>
> // Usage without lambda as desired
> std2::sort(dst, dst + srclen, cmp, &bwt_cmp_t::less);
> }
>
>
>
Unfortunately, it is not the same.
Unlike all previous variant, compiler implements this one via dynamic
dispatch (indirect call).
At least that's what I see with gcc compiler both at -O2 and at -O3.
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-09 14:39 +0300 |
| Message-ID | <ve5q1m$2kedt$1@dont-email.me> |
| In reply to | #120663 |
On 09.10.2024 13:58, Michael S wrote:
> On Wed, 9 Oct 2024 08:25:20 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
>> On 09.10.2024 01:06, Michael S wrote:
>>> On Wed, 9 Oct 2024 00:12:25 +0300
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>
>>>
>>>>
>>>> The context state is the bread and butter of lambda. If all you
>>>> want is to avoid operator(), this can be done easily:
>>>>
>>>
>>> I want neither operator() nor lambda.
>>> I want a way to feed std::sort with honest old [pointer to] object +
>>> [pointer to] its honest old member function. And I am not obsessed
>>> with idea that it has to be a single prameter at all cost; I see
>>> nothing wrong if two separate parameters needed to do the job.
>>>
>>
>> Not quite sure why you might want this, but here it goes:
>>
>> // Ugly lambda hidden in a common header
>> namespace std2 {
>> template<class ELEM, class COMP>
>> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool
>> (COMP::* member)(ELEM, ELEM) const) {
>> std::sort(begin, end, [&comp, member](const ELEM& a, const
>> ELEM& b) {return (comp.*member)(a, b); });
>> }
>> }
>>
>> // BWT sort - sort in lexicographic order with circular shift
>> void bwt_sort(int* dst, const uint8_t* src, int srclen) {
>> for (int i = 0; i < srclen; ++i)
>> dst[i] = i;
>>
>> struct bwt_cmp_t {
>> const uint8_t* src;
>> int srclen;
>> bool less(int a, int b) const {
>> if (a >= b) {
>> if (a > b)
>> return !less(b, a);
>> return false; // a == b
>> }
>> // a < b;
>> int diff = memcmp(&src[a], &src[b], srclen - b);
>> if (diff == 0) {
>> diff = memcmp(&src[a + srclen - b], &src[0], b - a);
>> if (diff == 0) {
>> diff = memcmp(&src[0], &src[b - a], a);
>> if (diff == 0)
>> return true; // stable sort
>> }
>> }
>> return diff < 0;
>> }
>> } cmp;
>> cmp.src = src;
>> cmp.srclen = srclen;
>>
>> // Usage without lambda as desired
>> std2::sort(dst, dst + srclen, cmp, &bwt_cmp_t::less);
>> }
>>
>>
>>
>
> Unfortunately, it is not the same.
> Unlike all previous variant, compiler implements this one via dynamic
> dispatch (indirect call).
> At least that's what I see with gcc compiler both at -O2 and at -O3.
That's right, one reason for preferring functional style functors and
lambdas over bare function pointers is that they can be optimized better
by the compiler, in general. But beauty requires sacrifice, so you have
to live with that!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-09 19:59 +0300 |
| Message-ID | <20241009195914.000045a5@yahoo.com> |
| In reply to | #120665 |
On Wed, 9 Oct 2024 14:39:34 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
> On 09.10.2024 13:58, Michael S wrote:
> > On Wed, 9 Oct 2024 08:25:20 +0300
> > Paavo Helde <eesnimi@osa.pri.ee> wrote:
> >
> >> On 09.10.2024 01:06, Michael S wrote:
> >>> On Wed, 9 Oct 2024 00:12:25 +0300
> >>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
> >>>
> >>>
> >>>>
> >>>> The context state is the bread and butter of lambda. If all you
> >>>> want is to avoid operator(), this can be done easily:
> >>>>
> >>>
> >>> I want neither operator() nor lambda.
> >>> I want a way to feed std::sort with honest old [pointer to]
> >>> object + [pointer to] its honest old member function. And I am
> >>> not obsessed with idea that it has to be a single prameter at all
> >>> cost; I see nothing wrong if two separate parameters needed to do
> >>> the job.
> >>
> >> Not quite sure why you might want this, but here it goes:
> >>
> >> // Ugly lambda hidden in a common header
> >> namespace std2 {
> >> template<class ELEM, class COMP>
> >> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool
> >> (COMP::* member)(ELEM, ELEM) const) {
> >> std::sort(begin, end, [&comp, member](const ELEM& a,
> >> const ELEM& b) {return (comp.*member)(a, b); });
> >> }
> >> }
> >>
> >> // BWT sort - sort in lexicographic order with circular shift
> >> void bwt_sort(int* dst, const uint8_t* src, int srclen) {
> >> for (int i = 0; i < srclen; ++i)
> >> dst[i] = i;
> >>
> >> struct bwt_cmp_t {
> >> const uint8_t* src;
> >> int srclen;
> >> bool less(int a, int b) const {
> >> if (a >= b) {
> >> if (a > b)
> >> return !less(b, a);
> >> return false; // a == b
> >> }
> >> // a < b;
> >> int diff = memcmp(&src[a], &src[b], srclen - b);
> >> if (diff == 0) {
> >> diff = memcmp(&src[a + srclen - b], &src[0], b -
> >> a); if (diff == 0) {
> >> diff = memcmp(&src[0], &src[b - a], a);
> >> if (diff == 0)
> >> return true; // stable sort
> >> }
> >> }
> >> return diff < 0;
> >> }
> >> } cmp;
> >> cmp.src = src;
> >> cmp.srclen = srclen;
> >>
> >> // Usage without lambda as desired
> >> std2::sort(dst, dst + srclen, cmp, &bwt_cmp_t::less);
> >> }
> >>
> >>
> >>
> >
> > Unfortunately, it is not the same.
> > Unlike all previous variant, compiler implements this one via
> > dynamic dispatch (indirect call).
> > At least that's what I see with gcc compiler both at -O2 and at
> > -O3.
>
> That's right, one reason for preferring functional style functors and
> lambdas over bare function pointers is that they can be optimized
> better by the compiler, in general. But beauty requires sacrifice, so
> you have to live with that!
>
>
>
>
>
Here is a variant without sacrifice. It is less pretty at the call site
- too many template arguments.
The advantage of it that it works the same both with std::sort and for
std::nth_element.
This variant uses normal function instead of member function. Not
because it is impossible to do the same with member, but because I am
not fluent with necessary syntax.
#include <cstdint>
#include <cstring>
#include <algorithm>
// Ugly template hidden in a common header
template < typename ELEM, typename Comparison_context,
bool Compare(Comparison_context,ELEM,ELEM) >
class TCompare3 {
const Comparison_context& m_context;
public:
TCompare3(const Comparison_context& a):m_context(a){};
bool operator() (ELEM a, ELEM b) {
return Compare(m_context, a, b);
}
};
// BWT sort - sort in lexicographic order with circular shift
void bwt_sort(int* dst, const uint8_t* src, int srclen)
{
for (int i = 0; i < srclen; ++i)
dst[i] = i;
struct bwt_cmp_t {
const uint8_t* src;
int srclen;
static
inline
bool less(bwt_cmp_t* obj, int a, int b) {
if (a >= b) {
if (a > b)
return !less(obj, b, a);
return false; // a == b
}
// a < b;
const uint8_t* src = obj->src;
const int srclen = obj->srclen;
int diff = memcmp(&src[a], &src[b], srclen - b);
if (diff == 0) {
diff = memcmp(&src[a + srclen - b], &src[0], b - a);
if (diff == 0) {
diff = memcmp(&src[0], &src[b - a], a);
if (diff == 0)
return true; // stable sort
}
}
return diff < 0;
}
} cmp;
cmp.src = src;
cmp.srclen = srclen;
std::sort(dst, dst + srclen,
TCompare3<int, bwt_cmp_t*, bwt_cmp_t::less>(&cmp));
}
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-10-09 22:37 +0300 |
| Message-ID | <ve6m1f$2our4$1@dont-email.me> |
| In reply to | #120666 |
On 09.10.2024 19:59, Michael S wrote:
> On Wed, 9 Oct 2024 14:39:34 +0300
> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>
>> On 09.10.2024 13:58, Michael S wrote:
>>> On Wed, 9 Oct 2024 08:25:20 +0300
>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>
>>>> On 09.10.2024 01:06, Michael S wrote:
>>>>> On Wed, 9 Oct 2024 00:12:25 +0300
>>>>> Paavo Helde <eesnimi@osa.pri.ee> wrote:
>>>>>
>>>>>
>>>>>>
>>>>>> The context state is the bread and butter of lambda. If all you
>>>>>> want is to avoid operator(), this can be done easily:
>>>>>>
>>>>>
>>>>> I want neither operator() nor lambda.
>>>>> I want a way to feed std::sort with honest old [pointer to]
>>>>> object + [pointer to] its honest old member function. And I am
>>>>> not obsessed with idea that it has to be a single prameter at all
>>>>> cost; I see nothing wrong if two separate parameters needed to do
>>>>> the job.
>>>>
>>>> Not quite sure why you might want this, but here it goes:
>>>>
>>>> // Ugly lambda hidden in a common header
>>>> namespace std2 {
>>>> template<class ELEM, class COMP>
>>>> void sort(ELEM* begin, ELEM* end, const COMP& comp, bool
>>>> (COMP::* member)(ELEM, ELEM) const) {
>>>> std::sort(begin, end, [&comp, member](const ELEM& a,
>>>> const ELEM& b) {return (comp.*member)(a, b); });
>>>> }
>>>> }
>>>>
>>>> // BWT sort - sort in lexicographic order with circular shift
>>>> void bwt_sort(int* dst, const uint8_t* src, int srclen) {
>>>> for (int i = 0; i < srclen; ++i)
>>>> dst[i] = i;
>>>>
>>>> struct bwt_cmp_t {
>>>> const uint8_t* src;
>>>> int srclen;
>>>> bool less(int a, int b) const {
>>>> if (a >= b) {
>>>> if (a > b)
>>>> return !less(b, a);
>>>> return false; // a == b
>>>> }
>>>> // a < b;
>>>> int diff = memcmp(&src[a], &src[b], srclen - b);
>>>> if (diff == 0) {
>>>> diff = memcmp(&src[a + srclen - b], &src[0], b -
>>>> a); if (diff == 0) {
>>>> diff = memcmp(&src[0], &src[b - a], a);
>>>> if (diff == 0)
>>>> return true; // stable sort
>>>> }
>>>> }
>>>> return diff < 0;
>>>> }
>>>> } cmp;
>>>> cmp.src = src;
>>>> cmp.srclen = srclen;
>>>>
>>>> // Usage without lambda as desired
>>>> std2::sort(dst, dst + srclen, cmp, &bwt_cmp_t::less);
>>>> }
>>>>
>>>>
>>>>
>>>
>>> Unfortunately, it is not the same.
>>> Unlike all previous variant, compiler implements this one via
>>> dynamic dispatch (indirect call).
>>> At least that's what I see with gcc compiler both at -O2 and at
>>> -O3.
>>
>> That's right, one reason for preferring functional style functors and
>> lambdas over bare function pointers is that they can be optimized
>> better by the compiler, in general. But beauty requires sacrifice, so
>> you have to live with that!
>>
>>
>>
>>
>>
>
> Here is a variant without sacrifice. It is less pretty at the call site
> - too many template arguments.
> The advantage of it that it works the same both with std::sort and for
> std::nth_element.
> This variant uses normal function instead of member function. Not
> because it is impossible to do the same with member, but because I am
> not fluent with necessary syntax.
>
> #include <cstdint>
> #include <cstring>
> #include <algorithm>
>
> // Ugly template hidden in a common header
> template < typename ELEM, typename Comparison_context,
> bool Compare(Comparison_context,ELEM,ELEM) >
> class TCompare3 {
> const Comparison_context& m_context;
> public:
> TCompare3(const Comparison_context& a):m_context(a){};
> bool operator() (ELEM a, ELEM b) {
> return Compare(m_context, a, b);
> }
> };
>
> // BWT sort - sort in lexicographic order with circular shift
> void bwt_sort(int* dst, const uint8_t* src, int srclen)
> {
> for (int i = 0; i < srclen; ++i)
> dst[i] = i;
>
> struct bwt_cmp_t {
> const uint8_t* src;
> int srclen;
> static
> inline
> bool less(bwt_cmp_t* obj, int a, int b) {
> if (a >= b) {
> if (a > b)
> return !less(obj, b, a);
> return false; // a == b
> }
> // a < b;
> const uint8_t* src = obj->src;
> const int srclen = obj->srclen;
> int diff = memcmp(&src[a], &src[b], srclen - b);
> if (diff == 0) {
> diff = memcmp(&src[a + srclen - b], &src[0], b - a);
> if (diff == 0) {
> diff = memcmp(&src[0], &src[b - a], a);
> if (diff == 0)
> return true; // stable sort
> }
> }
> return diff < 0;
> }
> } cmp;
> cmp.src = src;
> cmp.srclen = srclen;
> std::sort(dst, dst + srclen,
> TCompare3<int, bwt_cmp_t*, bwt_cmp_t::less>(&cmp));
> }
>
Interesting. Here, the address of the member function bwt_cmp_t::less is
not passed at run time, but rather the function is used as a template
parameter. I guess that's what avoids the "sacrifice".
The more I look at this, the more I like the lambda!
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-10 11:47 +0300 |
| Message-ID | <20241010114707.00006769@yahoo.com> |
| In reply to | #120667 |
On Wed, 9 Oct 2024 22:37:19 +0300 Paavo Helde <eesnimi@osa.pri.ee> wrote: > > The more I look at this, the more I like the lambda! > I am ready to admit that my requirement of "don't force user to write glue function with predefined name, especially so with predefined name starting with 'operator'" was artificial. In practice, writing one-liners operator(), as in my first post, is not a big deal.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-11 04:58 -0700 |
| Message-ID | <8634l2zw9m.fsf@linuxsc.com> |
| In reply to | #120651 |
Michael S <already5chosen@yahoo.com> writes: > On Wed, 9 Oct 2024 00:12:25 +0300 > Paavo Helde <eesnimi@osa.pri.ee> wrote: > >> The context state is the bread and butter of lambda. If all you >> want is to avoid operator(), this can be done easily: > > I want neither operator() nor lambda. > I want a way to feed std::sort with honest old [pointer to] object > + [pointer to] its honest old member function. And I am not > obsessed with idea that it has to be a single prameter at all > cost; I see nothing wrong if two separate parameters needed to do > the job. I think I understand your position. Without meaning to challenge that, I would like to offer my perspective on the situation. There are several ways a "stateful function" argument might be provided; some examples: pointer to function, along with either a separate context pointer or a bundled context/function pointer (illustrated in a recent post in comp.lang.c) having a parameter type of pointer to abstract superclass, with a virtual function to accommodate caller-specific functionality (not sure if a separate pointer-to-member argument makes sense here) a pointer-to templated class parameter, using either a fixed member function name or a separate pointer-to-member argument a lambda (which could be either a stateful lambda or a pure lambda along with a separate context argument) To me all of these choices are conceptually pretty much the same, having only minor differences in the details. A plausible analogy is comparing for() and while(), or if-then-else and switch(). Because I don't see much difference between them, what I want is whatever makes it most convenient for the caller. Usually "most convenient" means the choice that uses the least code in the caller, although that might be affected by how clunky the code is for the different cases. Of course which choice is most convenient depends on what is going on in the caller. In some cases a lambda is easiest; in other cases a templated class parameter with a separate pointer-to-member could be better. Which choice or choices should be accommodated depends on what the expected use cases are. The guiding principle remains What offers the easiest and best fit in the caller (or callers plural)? So for what it's worth there is my approach to the question.
[toc] | [prev] | [next] | [standalone]
Page 9 of 13 — ← Prev page 1 … 7 8 [9] 10 11 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web