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 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-10-11 16:03 +0300 |
| Message-ID | <20241011160349.00002b66@yahoo.com> |
| In reply to | #120700 |
On Fri, 11 Oct 2024 04:58:29 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > 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. I am looking at it from the point that one of the main promises of functionality supplied by <algorithm> header is zero cost of abstraction. For me it means that comparison routine can be inlined by compiler when appropriate and called with direct call otherwise. Experiments presented in other posts of this thread demonstrate that [current crop of major] compilers can't do it with your solution #1. It seems plausible to assume, even without experiments, that they can't do it with your solution # 2. For solution #4 it depends on details. At least the variant, proposed by Paavo is not sufficient. Solution #3 sort of works, but too many details, most critically types of parameters in comparison operations, have to be specified on the call site. I.e. solution #3 does not satisfy DRY principle, which is no less important than zero cost of abstraction. At the end, the original way (class with operator() as a glue) is practically the best, even if for my taste it feels "too functional". I consider this outcome as defect in STL API definitions. Mileage of others may vary.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-12 07:41 -0700 |
| Message-ID | <86plo5xu2a.fsf@linuxsc.com> |
| In reply to | #120701 |
Michael S <already5chosen@yahoo.com> writes: > On Fri, 11 Oct 2024 04:58:29 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> wrote: > >> 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. > > I am looking at it from the point that one of the main promises > of functionality supplied by <algorithm> header is zero cost of > abstraction. I understand that our criteria for what choice to make in various circumstances are not the same. I wasn't meaning to criticize your choices, just to explain my own. > For me it means that comparison routine can be inlined by compiler > when appropriate and called with direct call otherwise. Experiments > presented in other posts of this thread demonstrate that [current > crop of major] compilers can't do it with your solution #1. > It seems plausible to assume, even without experiments, that they > can't do it with your solution # 2. > For solution #4 it depends on details. [...] > Solution #3 sort of works, All of the four techniques listed above could be specialized or inlined by a suitable compiler. I accept that current compilers do that for only some of the techniques listed, but I see no reason to suppose that any of the four techniques are inherently better than the others in this regard. > but too many details, most critically > types of parameters in comparison operations, have to be specified > on the call site. I.e. solution #3 does not satisfy DRY principle, > which is no less important than zero cost of abstraction. I need to ask for further explanation here. It is commonly accepted, at least in the C/C++ world, that giving the same type name in two or more places is usually not "repeating yourself" but giving a redundant specification for the purpose of doing type checking, so there is value in forcing the redundancy. It seems like what you're objecting to is inherent in the C/C++ view of the world, and not something specific to stateful functions as arguments or parameters. > At the end, the original way (class with operator() as a glue) is > practically the best, even if for my taste it feels "too functional". > I consider this outcome as defect in STL API definitions. [...] I am baffled by your reaction to using operator(). To me it seems simple, natural, and a good fit to the most common cases while also being flexible enough to handle more elaborate cases. To me it seems no more or less functional than any of the other techniques being discussed. So I don't understand what it is about using operator() that you find objectionable.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-12 08:18 -0700 |
| Message-ID | <86ldytxsc5.fsf@linuxsc.com> |
| In reply to | #120646 |
Michael S <already5chosen@yahoo.com> writes:
[...]
> 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);
> }
I appreciate that this code illustrates your coding preferences.
For comparison here is an alternate approach to writing the
central routine (and also some incidental differences in other
parts of the code but those are not so important).
#include <cstring>
#include <algorithm>
// code for sorting rotations of a string in lexicographic order
typedef unsigned char U8;
class bwt_cmp_t {
const U8* s;
unsigned n;
public:
bwt_cmp_t( const U8 *s0, unsigned n0 ) : s(s0), n( n0 ) {}
bool
operator()( unsigned a, unsigned b ) const {
unsigned j, k, a1, b1, a2, b2;
int mc0, mc1, mc2;
if( a<b ) j = n-b, k = b-a, a1 = a+j, b1 = 0, a2 = 0, b2 = k;
else j = n-a, k = a-b, a1 = 0, b1 = b+j, a2 = k, b2 = 0;
if( mc0 = memcmp( s+a, s+b, j ), mc0 ) return mc0 < 0;
if( mc1 = memcmp( s+a1, s+b1, k ), mc1 ) return mc1 < 0;
mc2 = memcmp( s+a2, s+b2, n-j-k );
return mc2 < 0 || mc2 == 0 && a <= b;
}
};
void
bwt_sort( unsigned* dst, U8* s, unsigned n ){
for( unsigned i = 0; i < n; ++i ) dst[i] = i;
std::sort( dst, dst + n, bwt_cmp_t( s, n ) );
}
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-10-11 03:57 -0700 |
| Message-ID | <86a5fazz2s.fsf@linuxsc.com> |
| In reply to | #120626 |
Michael S <already5chosen@yahoo.com> writes: > 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. I must confess I am still somewhat baffled, although I do get a sense of what you're reacting to. For now I will leave it at that; thank you for the explanation.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-10-07 19:19 +0200 |
| Message-ID | <ve1571$1ptnn$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120603 |
Am 06.10.2024 um 13:19 schrieb Michael S:
> 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.
I use functional programming all the day. F.e. this shows a lookup if
a certain file exists. So there's no allocation of a vector with the
file entries and the FindFirstFile() / FindNextFike() processing stops
if the file was found.
fileList( widenString( fileName ).c_str(),
tmpref( [&]( WIN32_FIND_DATAW const &fdw ) -> bool { existing = true;
return false; } ) );;
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-10-02 07:13 +0000 |
| Message-ID | <vdirrh$358h8$1@dont-email.me> |
| In reply to | #120520 |
On Tue, 1 Oct 2024 21:50:50 +0300 Michael S <already5chosen@yahoo.com> boring babbled: >On Tue, 1 Oct 2024 16:13:29 -0000 (UTC) >Muttley@DastartdlyHQ.org wrote: >> Personally I prefer seperate function names instead of overloaded >> functions and I don't often like operator overloading but they're >> part of C++. Presumably you feel the same way? Can't have it both >> ways mate. >> > >I do feel the same way, but that's completely differrent issue. > >The best C++ solution (actually, it is the best solution not just in C++ >but in any language that is not pure functional) for your 'value >polimorphism' example is not separte function names, but a single >function with switch in the body. Yes, obviously. But thats wandering into the "C can do anything C++ can do" (and same for assember and C) territory. Thats not the point , the point is to make things simpler in some circumstances. >And best (for me, personally, YMMV) solution in pure functional >languges is to avoid programming in such languages. Well I don't use them day to day either.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-01 13:06 +0200 |
| Message-ID | <vdgl2q$2mnb9$1@dont-email.me> |
| In reply to | #120497 |
On 01/10/2024 11:53, Michael S wrote: > On Tue, 1 Oct 2024 10:42:06 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 01/10/2024 10:00, Bonita Montero wrote: >>> Am 01.10.2024 um 09:36 schrieb Muttley@DastartdlyHQ.org: >>> >>>> Given his apparently inability to understand simple example code >>>> I very much doubt that. He probably struggles with something like >>>> SQL being so completely different to C++. >>> >>> Do you mean me with "he" ? I've got a OCP-DBA for Oracle and I've >>> been a DBA two years. >>> You don't even try to read my code, telling that my code doesn't >>> make sense and it's too complicated. >>> >>>> Big deal. This is runtime, not compile time. >>> >>> Tell me which popular language implements this "value-polymorphism". >>> It's a word Wikipedia doesn't know. >>> >> >> Of course Wikipedia doesn't know it, since it is his own made-up >> term. (Well, his and one other person.) >> >> The word "polymorphism" means "multiple kinds" or "multiple shapes" - >> it is a term for code that can handle a parameter that can be of many >> different types. So in C++ terms (since this is comp.lang.c++, even >> though Muttley seems to think it is comp.lang.made-up-stuff), you can >> have run-time polymorphism using pointers to base classes and virtual >> functions, and compile-time polymorphism using generics and templates. >> >> What you can't have is "value" polymorphism - it's an oxymoron. > > I don't think so. > IMHO, C++ does have features that can be called compile-time value > polymorphism without overstretching definition of the word > 'polymorphism'. > You demonstrated it yourself few posts ago using relatively modern > C++ features. It is not polymorphism. What I demonstrated is value pattern matching, and splitting the definition up. You could, at a stretch, call it overloading by compile-time constant value. Polymorphism is about /types/. And the distinguishing feature from overloading is that the polymorphic code is generic to types with certain characteristics, not a pre-defined limited set of types. Thus : void foo(int); void foo(double); is a set of overloads, while: void foo(auto x); is (compile-time) polymorphic. In compile-time polymorphic code, the function cannot be compiled when it is defined - it is only when the function is used that the types are known and the function can be compiled. This is different from overloading. For run-time polymorphic code, the polymorphic function /can/ be compiled because the parameter passed contains enough information to determine the real type, or at least the required real functionality of the type. In C++, this is usually done by virtual functions, but it can also be done using std::any. > But for class templates (as opposed to function > templates) something that can be reasonably called 'value polymorphism' > existed for as long as C++ has templates (1990 ?). Class and function templates are polymorphic when they have type parameters, and these have been around from early on (I think some time between the second edition of "The C++ Programming Language" in 1991, and the first C++ standard in 1998). I believe non-type template parameters came later than type template parameters, but I don't know the historical details. They have, certainly, been around for a long time. But while non-type template parameters are perhaps a better candidate for "value polymorphism" than anything else in C++, they are not polymorphic. > > The feature appears useful in 'pure functional' languages like C++ > template sub-language. Templates and template specialisation are certainly useful, as is the pattern matching found in functional languages. I am not arguing that this kind of thing does not exist in languages, or that it is not useful - I am arguing that it is not known as "value polymorphism" and is not "polymorphism" at all, as the term is generally used. > Of course, it is less useful, and probably not > desirable in mixed functional/imperative environments where you can > achieve the same result in several simpler ways. > >> The >> common term for code that can handle parameters taking multiple >> different values is "function". >> >
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-10-01 10:01 +0000 |
| Message-ID | <vdgh9i$2mdpk$1@dont-email.me> |
| In reply to | #120495 |
On Tue, 1 Oct 2024 10:42:06 +0200 David Brown <david.brown@hesbynett.no> boring babbled: >What you can't have is "value" polymorphism - it's an oxymoron. The No it isn't, your brain just can't understand the concept even with now 2 pieces of example code. >common term for code that can handle parameters taking multiple >different values is "function". So C++ can differentiate a functions with the same name based on the passed value at runtime can it? Not last time I checked. >Muttley doesn't even seem to know what he means by the term. He has I know perfectly well what it means, you're just dim. tl;dr
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-10-01 13:08 +0200 |
| Message-ID | <vdgl7f$2mnb9$2@dont-email.me> |
| In reply to | #120501 |
On 01/10/2024 12:01, Muttley@DastartdlyHQ.org wrote:
> On Tue, 1 Oct 2024 10:42:06 +0200
> David Brown <david.brown@hesbynett.no> boring babbled:
>> What you can't have is "value" polymorphism - it's an oxymoron. The
>
> No it isn't, your brain just can't understand the concept even with now
> 2 pieces of example code.
I know exactly what you mean by your example. But it is not
"polymorphism" of any sort.
>
>> common term for code that can handle parameters taking multiple
>> different values is "function".
>
> So C++ can differentiate a functions with the same name based on the
> passed value at runtime can it? Not last time I checked.
>
void foo(int x) {
if (x == 0) {
printf("Muttley ");
} else if (x == 1) {
printf("has no idea ");
} else {
printf("what he is talking about.\n");
}
}
>> Muttley doesn't even seem to know what he means by the term. He has
>
> I know perfectly well what it means, you're just dim.
>
> tl;dr
>
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-10-01 16:15 +0000 |
| Message-ID | <vdh76n$2q55r$1@dont-email.me> |
| In reply to | #120507 |
On Tue, 1 Oct 2024 13:08:31 +0200 David Brown <david.brown@hesbynett.no> boring babbled: >On 01/10/2024 12:01, Muttley@DastartdlyHQ.org wrote: >> On Tue, 1 Oct 2024 10:42:06 +0200 >> David Brown <david.brown@hesbynett.no> boring babbled: >>> What you can't have is "value" polymorphism - it's an oxymoron. The >> >> No it isn't, your brain just can't understand the concept even with now >> 2 pieces of example code. > >I know exactly what you mean by your example. But it is not >"polymorphism" of any sort. Whatever. I'm tired of arguing semantics. You're just moving goalposts in order not to look stupid in hindsight. Have it your way.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-10-01 19:44 +0200 |
| Message-ID | <vdhcd6$2r0pi$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120513 |
Am 01.10.2024 um 18:15 schrieb Muttley@DastartdlyHQ.org: > On Tue, 1 Oct 2024 13:08:31 +0200 > David Brown <david.brown@hesbynett.no> boring babbled: >> On 01/10/2024 12:01, Muttley@DastartdlyHQ.org wrote: >>> On Tue, 1 Oct 2024 10:42:06 +0200 >>> David Brown <david.brown@hesbynett.no> boring babbled: >>>> What you can't have is "value" polymorphism - it's an oxymoron. The >>> >>> No it isn't, your brain just can't understand the concept even with now >>> 2 pieces of example code. >> >> I know exactly what you mean by your example. But it is not >> "polymorphism" of any sort. > > Whatever. I'm tired of arguing semantics. You're just moving > goalposts in order not to look stupid in hindsight. Have it > your way. Youre misusing and inventing your own terms.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@DastartdlyHQ.org |
|---|---|
| Date | 2024-10-01 09:56 +0000 |
| Message-ID | <vdggvp$2mc6q$1@dont-email.me> |
| In reply to | #120492 |
On Tue, 1 Oct 2024 10:00:57 +0200 Bonita Montero <Bonita.Montero@gmail.com> boring babbled: >Am 01.10.2024 um 09:36 schrieb Muttley@DastartdlyHQ.org: > >> Given his apparently inability to understand simple example code >> I very much doubt that. He probably struggles with something like >> SQL being so completely different to C++. > >Do you mean me with "he" ? I've got a OCP-DBA for Oracle and I've No.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-10-01 13:01 +0200 |
| Message-ID | <vdgkpf$2muco$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120498 |
Am 01.10.2024 um 11:56 schrieb Muttley@DastartdlyHQ.org: > On Tue, 1 Oct 2024 10:00:57 +0200 > Bonita Montero <Bonita.Montero@gmail.com> boring babbled: >> Am 01.10.2024 um 09:36 schrieb Muttley@DastartdlyHQ.org: >> >>> Given his apparently inability to understand simple example code >>> I very much doubt that. He probably struggles with something like >>> SQL being so completely different to C++. >> >> Do you mean me with "he" ? I've got a OCP-DBA for Oracle and I've > > No. > > If that makes feel you better ...
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-29 15:00 +0000 |
| Message-ID | <vdbq2a$1plkp$1@dont-email.me> |
| In reply to | #120446 |
On Sun, 29 Sep 2024 13:41:27 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 28/09/2024 17:47, Muttley@dastardlyhq.com wrote: >> On Sat, 28 Sep 2024 17:33:46 +0200 >> David Brown <david.brown@hesbynett.no> gabbled: >>> On 28/09/2024 11:12, Muttley@dastardlyhq.com wrote: >>>> On Fri, 27 Sep 2024 18:24:11 +0200 >>>> Not sure how that differs with value polymorphism. >>>> >>> >>> I explained that - look at my answer below for another attempt. >> >> No you didn't because like Bonita you have no idea what value >> polymorphism is. > > >The term "polymorphism" is used in reference to /types/, not /values/. Says who? >I am not new to programming, and have used a large variety of languages >(including functional programming languages), but have not heard the Could have fooled me. >phrase "value polymorphism" before. So I am trying to get /you/ to say >what /you/ mean by it. Maybe it's just a name you and a few other >people use for pattern matching. I don't know how many more bloody times I can explain it, its not complicated! I even posted some functional code a few days ago demonstrating it! Frankly I can't be bothered arguing the toss any longer. Clearly you don't understand what it is so tough luck, thats your problem , not mine. >> Really? What exactly do you think an assembler call instruction is other >> than a single opcode stack push and jump? > >Yes, that's what a call instruction sequence is on many (but certainly >not all) processors. But that's not what you wrote. You wrote that >"all types of polymorphism" are just conditionals that boil down to >"cmp/jmp" instructions. They are conditions and could be compiled down to a compare and jump just like any other conditional code.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-29 14:37 +0300 |
| Message-ID | <20240929143757.00000336@yahoo.com> |
| In reply to | #120435 |
On Sat, 28 Sep 2024 17:33:46 +0200 David Brown <david.brown@hesbynett.no> wrote: > On 28/09/2024 11:12, Muttley@dastardlyhq.com wrote: > > On Fri, 27 Sep 2024 18:24:11 +0200 > > David Brown <david.brown@hesbynett.no> gabbled: > >> > >> This cannot be done with a series of cmp/jmp instructions - it > >> ends up as an indirect call instruction. > > > > It could quite easily, but yes, a call is more likely. Point still > > stands however. > > > > No, it could not be done - thus your point does /not/ stand. > It could be done. It could be done relatively easily with whole program compiler. Without whole program compiler it still could be done, but would need some co-operation from linker that would have to glue code segments. I'd guess, majority of linkers already can do something of this sort for other purposes. Of course, if class hierarchy is sufficiently big then implementation based on comparisons, branches and direct calls would be rather inefficient relatively to indirect call (actually dual-indirect call in most typical C++ implementations). They point that you were probably missing when claiming that it is impossible is that every instance of given class can carry its Class Id.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-29 15:42 +0200 |
| Message-ID | <vdblff$1osuh$1@dont-email.me> |
| In reply to | #120445 |
On 29/09/2024 13:37, Michael S wrote: > On Sat, 28 Sep 2024 17:33:46 +0200 > David Brown <david.brown@hesbynett.no> wrote: > >> On 28/09/2024 11:12, Muttley@dastardlyhq.com wrote: >>> On Fri, 27 Sep 2024 18:24:11 +0200 >>> David Brown <david.brown@hesbynett.no> gabbled: >>>> >>>> This cannot be done with a series of cmp/jmp instructions - it >>>> ends up as an indirect call instruction. >>> >>> It could quite easily, but yes, a call is more likely. Point still >>> stands however. >>> >> >> No, it could not be done - thus your point does /not/ stand. >> > > It could be done. > It could be done relatively easily with whole program compiler. I think I mentioned that - and I specifically mentioned separate compilation. But of course if the compiler has full knowledge of the actual types being used at the time, then it can use conditionals or other techniques (like code cloning) to improve the efficiency. Compilers do de-virtualisation when they can, and with whole program optimisation, they can do so more often. Still, the key point is that the source code is written independently of the actual type used - there are no "if" or "switch" clauses in the source, or any kind of pattern matching between a pre-specified set of types. > Without whole program compiler it still could be done, but would need > some co-operation from linker that would have to glue code segments. > I'd guess, majority of linkers already can do something of this sort > for other purposes. You are perhaps thinking of things like sequences of pre-main constructors or initialisation functions, that are often joined together by the linker? It's certainly conceivable that the base class code for the virtual function could be generated with a template for a series of "if the real type is this, do that" blocks in a named segment, with a default handler, then each inheriting class which overrides the method could add "if the real type is this type, do this" block to this named segment. Then the linker would put it all together. I would be extremely surprised if that was more efficient at run-time than function-pointer style overloads using virtual method tables, and it would be a lot more complex to implement, but I'll agree it should be possible. > Of course, if class hierarchy is sufficiently big then implementation > based on comparisons, branches and direct calls would be rather > inefficient relatively to indirect call (actually dual-indirect call in > most typical C++ implementations). > > They point that you were probably missing when claiming that it is > impossible is that every instance of given class can carry its Class Id. > I will accept that it is /possible/ to use conditionals, rather than indirect jumps or calls. But it is not possible without more information available when implementing the polymorphic code - whether by whole-program optimisation, or smart linkers, or by having all the code in one translation unit.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-29 15:47 +0200 |
| Message-ID | <vdblpf$1p0tm$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120449 |
Am 29.09.2024 um 15:42 schrieb David Brown: > I think I mentioned that - and I specifically mentioned separate > compilation. But of course if the compiler has full knowledge of the > actual types being used at the time, then it can use conditionals or > other techniques (like code cloning) to improve the efficiency. > Compilers do de-virtualisation when they can, and with whole program > optimisation, they can do so more often. That actually doesn't happen often until a class is marked as final. And if you chose to use virtual functions you usually have varying destinations among the objects. > Still, the key point is that the source code is written independently > of the actual type used - there are no "if" or "switch" clauses in the > source, or any kind of pattern matching between a pre-specified set of > types. Except with "value polymorphism". ;-)
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-28 04:28 -0700 |
| Message-ID | <86jzew3tla.fsf@linuxsc.com> |
| In reply to | #120411 |
Muttley@dastardlyhq.com writes: > On Fri, 27 Sep 2024 02:27:52 -0700 > Tim Rentsch <tr.17687@z991.linuxsc.com> boringly babbled: > >> Muttley@dastardlyhq.com writes: >> >>> Thanks for proving my point. A proper functional language has value >>> polymorphism (which clearly you don't understand) as well as type >>> polymorphism. >>> >>> https://chrisdone.com/posts/value-polymorphism/ >> >> Neither "value polymorphism" nor "polymorphism by value" is a >> common term. > > Because not many languages support it. > >> They mean different things. > > Not in the version of english I speak they don't. > >> Polymorphism by value was discussed in a 1993 paper by Xavier >> Leroy. > > Who? > >> Value polymorphism, as it is described in the cited web page, is >> simply overloading of variables rather than functions. >> (Overloading is often called "ad hoc polymorphism".) > > Thats his opinion. > >> Neither overloading of functions nor overloading of variables has >> anything to do with functional programming. Overloading might be > > Without it many of the standard examples of functional programming simply > won't run. > >> that don't have facilities for polymorphism, as for example the >> original Lisp. > > Since when was Lisp a functional language? Scheme maybe. Judging by these responses, it seems you have no real interest in having a useful conversation.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-28 13:55 +0000 |
| Message-ID | <vd91s2$18vtr$1@dont-email.me> |
| In reply to | #120432 |
On Sat, 28 Sep 2024 04:28:49 -0700 Tim Rentsch <tr.17687@z991.linuxsc.com> gabbled: >Muttley@dastardlyhq.com writes: > >> On Fri, 27 Sep 2024 02:27:52 -0700 >> Tim Rentsch <tr.17687@z991.linuxsc.com> boringly babbled: >> >>> Muttley@dastardlyhq.com writes: >>> >>>> Thanks for proving my point. A proper functional language has value >>>> polymorphism (which clearly you don't understand) as well as type >>>> polymorphism. >>>> >>>> https://chrisdone.com/posts/value-polymorphism/ >>> >>> Neither "value polymorphism" nor "polymorphism by value" is a >>> common term. >> >> Because not many languages support it. >> >>> They mean different things. >> >> Not in the version of english I speak they don't. >> >>> Polymorphism by value was discussed in a 1993 paper by Xavier >>> Leroy. >> >> Who? >> >>> Value polymorphism, as it is described in the cited web page, is >>> simply overloading of variables rather than functions. >>> (Overloading is often called "ad hoc polymorphism".) >> >> Thats his opinion. >> >>> Neither overloading of functions nor overloading of variables has >>> anything to do with functional programming. Overloading might be >> >> Without it many of the standard examples of functional programming simply >> won't run. >> >>> that don't have facilities for polymorphism, as for example the >>> original Lisp. >> >> Since when was Lisp a functional language? Scheme maybe. > >Judging by these responses, it seems you have no real interest in >having a useful conversation. Thank you for your valuable insight and contribution.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 15:33 +0000 |
| Message-ID | <vd1ag3$3nu7q$1@dont-email.me> |
| In reply to | #120314 |
On Wed, 25 Sep 2024 16:14:28 +0200
Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>Am 25.09.2024 um 16:11 schrieb Muttley@dastardlyhq.com:
>> On Wed, 25 Sep 2024 15:44:21 +0200
>> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
>>> Am 25.09.2024 um 15:36 schrieb Muttley@dastardlyhq.com:
>>>
>>>> If you're writing C++ you're not doing functional programming, period.
>>>
>>> C++ supports functional programming since C++11, but doesn't mandate
>>> pure functional programming.
>>
>> Functional style programming != functional programming.
>
>You make up your own definitions so that
>you somehow feel like you were right.
>
>> Which part of polymorphism by value did you not understand?
>
>I understand both types of polymorphism, you nothing.
You don't have clue. This is the sort of thing I'm talking abouit:
def main(argv) ->
func("",["hello","cruel","world","this","is","a","test"])
: 0
;
def func(_,[]) -> "";
def func(_,[head<tail]) -> printnl head,",",tail : func(head[0],tail);
def func("world",[head<tail]) ->
printnl "GOT WORLD" : func(head,tail);
[toc] | [prev] | [next] | [standalone]
Page 10 of 13 — ← Prev page 1 … 8 9 [10] 11 12 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web