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 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 11:20 +0200 |
| Message-ID | <vd390n$4iap$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120356 |
Am 26.09.2024 um 10:46 schrieb wij:
> From the last time I saw your ring_deque, I found you don't understand
> what the ring buffer is. ...
I implemented a ring buffer and it works.
> And, a for loop caught my attention, it should be like this (just a few from my memory, because I had some memory C/C++ beginners
> like to write 'smart' programs):
>
> for(size_t i=arr.capacity(); i--; ) {
> // access all element of arr
> }
I never used capacity on something else but I implemented a capacity()
function. The memory I allocated is accessed through a span, which
doesn't have a capacity.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-09-26 19:17 +0800 |
| Message-ID | <c28473d57c1b2e150bc7c6e61e2230e43c29c67d.camel@gmail.com> |
| In reply to | #120359 |
On Thu, 2024-09-26 at 11:20 +0200, Bonita Montero wrote:
> Am 26.09.2024 um 10:46 schrieb wij:
>
> > From the last time I saw your ring_deque, I found you don't understand
> > what the ring buffer is. ...
>
> I implemented a ring buffer and it works.
>
> > And, a for loop caught my attention, it should be like this (just a few from my memory, because I
> > had some memory C/C++ beginners
> > like to write 'smart' programs):
> >
> > for(size_t i=arr.capacity(); i--; ) {
> > // access all element of arr
> > }
>
>
> I never used capacity on something else but I implemented a capacity()
> function. The memory I allocated is accessed through a span, which
> doesn't have a capacity.
>
Sorry, the code is from a different post I copied and tested, forgot which post.
#include <iostream>
#include <random>
#include <algorithm>
#include <map>
#include <climits>
using namespace std;
int main(int argc, char** argv)
{
mt19937_64 mt;
uniform_int_distribution<int> uid( INT_MAX, INT_MAX );
vector<int> vi;
vi.reserve( 1'000 );
for( size_t i = vi.capacity(); i--; )
vi.emplace_back(uid( mt ));
using map_t = map<void *, size_t>;
map_t
fnAdresses,
localAddresses;
bool invert = argc > 1;
sort( vi.begin(), vi.end(),
[&, invert = invert]( int lhs, int rhs )
{
++fnAdresses[(void *)&invert];
char c;
++localAddresses[&c];
if( !invert )
return lhs < rhs;
else
return rhs < lhs;
} );
auto print = []( char const *prefix, map_t const &map )
{
if( !map.size() )
return;
cout << prefix << endl;
char const *min = (char *)map.begin()->first;
size_t i = 0;
for( auto &kv : map )
cout << "\t" << i++ << ":\t" << (void *)kv.first << ", " <<
(char*)kv.first - (char*)min << ", " << kv.second << endl;
};
print( "fn:", fnAdresses );
print( "local:", localAddresses );
}
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-09-26 19:27 +0800 |
| Message-ID | <94b0f78e8b73df89cc5b9bbff21361258ef91954.camel@gmail.com> |
| In reply to | #120359 |
On Thu, 2024-09-26 at 11:20 +0200, Bonita Montero wrote:
> Am 26.09.2024 um 10:46 schrieb wij:
>
> > From the last time I saw your ring_deque, I found you don't understand
> > what the ring buffer is. ...
>
> I implemented a ring buffer and it works.
>
The implement of ring_deque looked like a deque, not a "ring buffer".
Ring buffer is fixed sized (e.g. N). In short, you can keep pushing data into it,
the ring buffer can only keep the last N elements.
> > And, a for loop caught my attention, it should be like this (just a few from my memory, because I
> > had some memory C/C++ beginners
> > like to write 'smart' programs):
> >
> > for(size_t i=arr.capacity(); i--; ) {
> > // access all element of arr
> > }
>
>
> I never used capacity on something else but I implemented a capacity()
> function. The memory I allocated is accessed through a span, which
> doesn't have a capacity.
>
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 13:32 +0200 |
| Message-ID | <vd3goe$5op3$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120369 |
Am 26.09.2024 um 13:27 schrieb wij: > The implement of ring_deque looked like a deque, not a "ring buffer". Internally it's a ring-buffer with a sliding window.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-26 12:23 +0300 |
| Message-ID | <20240926122341.0000504f@yahoo.com> |
| In reply to | #120356 |
On Thu, 26 Sep 2024 16:46:08 +0800
wij <wyniijj5@gmail.com> wrote:
> On Thu, 2024-09-26 at 10:20 +0200, Bonita Montero wrote:
> > Am 26.09.2024 um 09:34 schrieb Muttley@dastardlyhq.com:
> > > On Wed, 25 Sep 2024 17:53:58 +0200
> > > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
> > > > Am 25.09.2024 um 17:49 schrieb Muttley@dastardlyhq.com:
> > > >
> > > > > Thanks for proving my point. A proper functional language has
> > > > > value polymorphism (which clearly you don't understand) ...
> > > >
> > > > You've probably never dealt with std::function<> objects. That's
> > > > value polymorphism! I use that all the dayd, f.e. with this
> > > > function:
> > >
> > > [Usual unreadable mess snipped]
> >
> > My collegue calls my code "too beautiful".
> >
>
> I would call "too academic" or too much brain-washed by c++std stuff.
>
> From the last time I saw your ring_deque, I found you don't understand
> what the ring buffer is. And, a for loop caught my attention, it
> should be like this (just a few from my memory, because I had some
> memory C/C++ beginners like to write 'smart' programs):
>
> for(size_t i=arr.capacity(); i--; ) {
> // access all element of arr
> }
>
> Normally, the for loop should be like "for(size_t i=0 ; i>=0; --i) {
> /* stuff */ } (I forgot to chk whether 'capacity' is correct or not)
>
It looks like infinite loop.
Didn't you mean either
for(size_t i=arr.capacity() ; i>0; --i)
or
for(ptrdiff_t i=ptrdiff_t(arr.capacity())-1; i>=0; --i)
?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 11:25 +0200 |
| Message-ID | <vd399r$4k8d$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120360 |
Am 26.09.2024 um 11:23 schrieb Michael S: > It looks like infinite loop. > Didn't you mean either > for(size_t i=arr.capacity() ; i>0; --i) > or > for(ptrdiff_t i=ptrdiff_t(arr.capacity())-1; i>=0; --i) > ? There's no such loop in my code. I'm not using capacity on any foreign object but I implement capacity-functions myself. And I rarely use an integer-index to iterate over a linear container but I use iterators because this is sometimes faster.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-09-26 19:20 +0800 |
| Message-ID | <57cc2b5e66f64c42709c1fd83ffb08e585876b2c.camel@gmail.com> |
| In reply to | #120360 |
On Thu, 2024-09-26 at 12:23 +0300, Michael S wrote:
> On Thu, 26 Sep 2024 16:46:08 +0800
> wij <wyniijj5@gmail.com> wrote:
>
> > On Thu, 2024-09-26 at 10:20 +0200, Bonita Montero wrote:
> > > Am 26.09.2024 um 09:34 schrieb Muttley@dastardlyhq.com:
> > > > On Wed, 25 Sep 2024 17:53:58 +0200
> > > > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled:
> > > > > Am 25.09.2024 um 17:49 schrieb Muttley@dastardlyhq.com:
> > > > >
> > > > > > Thanks for proving my point. A proper functional language has
> > > > > > value polymorphism (which clearly you don't understand) ...
> > > > >
> > > > > You've probably never dealt with std::function<> objects. That's
> > > > > value polymorphism! I use that all the dayd, f.e. with this
> > > > > function:
> > > >
> > > > [Usual unreadable mess snipped]
> > >
> > > My collegue calls my code "too beautiful".
> > >
> >
> > I would call "too academic" or too much brain-washed by c++std stuff.
> >
> > From the last time I saw your ring_deque, I found you don't understand
> > what the ring buffer is. And, a for loop caught my attention, it
> > should be like this (just a few from my memory, because I had some
> > memory C/C++ beginners like to write 'smart' programs):
> >
> > for(size_t i=arr.capacity(); i--; ) {
> > // access all element of arr
> > }
> >
> > Normally, the for loop should be like "for(size_t i=0 ; i>=0; --i) {
> > /* stuff */ } (I forgot to chk whether 'capacity' is correct or not)
> >
>
> It looks like infinite loop.
> Didn't you mean either
> for(size_t i=arr.capacity() ; i>0; --i)
> or
> for(ptrdiff_t i=ptrdiff_t(arr.capacity())-1; i>=0; --i)
> ?
>
I was address the code from:
#include <iostream>
#include <random>
#include <algorithm>
#include <map>
#include <climits>
using namespace std;
int main(int argc, char** argv)
{
mt19937_64 mt;
uniform_int_distribution<int> uid( INT_MAX, INT_MAX );
vector<int> vi;
vi.reserve( 1'000 );
for( size_t i = vi.capacity(); i--; ) // <--- HERE
vi.emplace_back(uid( mt ));
using map_t = map<void *, size_t>;
map_t
fnAdresses,
localAddresses;
bool invert = argc > 1;
sort( vi.begin(), vi.end(),
[&, invert = invert]( int lhs, int rhs )
{
++fnAdresses[(void *)&invert];
char c;
++localAddresses[&c];
if( !invert )
return lhs < rhs;
else
return rhs < lhs;
} );
auto print = []( char const *prefix, map_t const &map )
{
if( !map.size() )
return;
cout << prefix << endl;
char const *min = (char *)map.begin()->first;
size_t i = 0;
for( auto &kv : map )
cout << "\t" << i++ << ":\t" << (void *)kv.first << ", " <<
(char*)kv.first - (char*)min << ", " << kv.second << endl;
};
print( "fn:", fnAdresses );
print( "local:", localAddresses );
}
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-26 10:03 +0000 |
| Message-ID | <vd3bgk$4vcf$1@dont-email.me> |
| In reply to | #120350 |
On Thu, 26 Sep 2024 10:20:53 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 26.09.2024 um 09:34 schrieb Muttley@dastardlyhq.com: >> On Wed, 25 Sep 2024 17:53:58 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >>> Am 25.09.2024 um 17:49 schrieb Muttley@dastardlyhq.com: >>> >>>> Thanks for proving my point. A proper functional language has >>>> value polymorphism (which clearly you don't understand) ... >>> >>> You've probably never dealt with std::function<> objects. That's >>> value polymorphism! I use that all the dayd, f.e. with this function: >> >> [Usual unreadable mess snipped] > >My collegue calls my code "too beautiful". Sarcasm probably. >>> You can pass a lambda to this function and the type-polymorphism >>> becomes a value-polymophism. > >> Oh dear. Thats not value polymorphism, thats a very complicated way of doing >> if-then. > >You can consider it like that, but it's sill polymorphism because theres >state and a pointer-dispatched function which is caalled on this state. Value polymorphism requires the value to be in the function prototype, not buried in some code underneath. Like all polymorphism its just a syntatic and semantic nicety as it can simply be done using if-then style code.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 13:33 +0200 |
| Message-ID | <vd3gql$5op3$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120363 |
Am 26.09.2024 um 12:03 schrieb Muttley@dastardlyhq.com: > Value polymorphism requires the value to be in the function prototype, not > buried in some code underneath. Like all polymorphism its just a syntatic > and semantic nicety as it can simply be done using if-then style code. Calling a function<>-object is always value polymorphism.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-26 14:09 +0000 |
| Message-ID | <vd3pv6$76pu$1@dont-email.me> |
| In reply to | #120373 |
On Thu, 26 Sep 2024 13:33:49 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 26.09.2024 um 12:03 schrieb Muttley@dastardlyhq.com: > >> Value polymorphism requires the value to be in the function prototype, not >> buried in some code underneath. Like all polymorphism its just a syntatic >> and semantic nicety as it can simply be done using if-then style code. > >Calling a function<>-object is always value polymorphism. I give up, believe what you like.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 16:14 +0200 |
| Message-ID | <vd3q7d$77q7$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120363 |
Am 26.09.2024 um 12:03 schrieb Muttley@dastardlyhq.com: > Value polymorphism requires the value to be in the function prototype, not > buried in some code underneath. Like all polymorphism its just a syntatic > and semantic nicety as it can simply be done using if-then style code. There's no conditional jump inside a function<>-object to decide which function actually to call. And when you use function<>-objects you need loose coupelng and then ifs are no alternative.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-09-27 02:27 -0700 |
| Message-ID | <86h6a15tuv.fsf@linuxsc.com> |
| In reply to | #120327 |
Muttley@dastardlyhq.com writes: > On Wed, 25 Sep 2024 17:33:41 +0200 > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: > >> Am 25.09.2024 um 17:32 schrieb Muttley@dastardlyhq.com: >> >>>> I understand both types of polymorphism, you nothing. >>> >>> You don't have clue. ... >> >> And you have your own definition of polymorphism. > > 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. They mean different things. Polymorphism by value was discussed in a 1993 paper by Xavier Leroy. 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".) Neither overloading of functions nor overloading of variables has anything to do with functional programming. Overloading might be supported in some functional programming languages (and it is in some non-functional languages, notably C++), but overloading is orthogonal to the notion of functional programming. Supporting polymorphism is not a pre-requisite either for doing functional programming or for a language being a functional language. There are plenty of functional programming languages that don't have facilities for polymorphism, as for example the original Lisp.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-27 11:11 +0000 |
| Message-ID | <vd63t7$n6kc$1@dont-email.me> |
| In reply to | #120410 |
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.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-27 16:14 +0200 |
| Message-ID | <vd6ek5$ollh$1@dont-email.me> |
| In reply to | #120411 |
On 27/09/2024 13:11, Muttley@dastardlyhq.com wrote: > 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. > <snip> >> 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. > Are you talking about what is more commonly referred to as pattern matching? factorial 0 = 1 factorial n = n * factorial (n - 1) That is not what is generally meant by polymorphism, it's just an alternative (but often very neat) way to write a conditional : factorial n = if n < 2 then 1 else n * factorial (n - 1)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-27 15:25 +0000 |
| Message-ID | <vd6iov$pc4k$1@dont-email.me> |
| In reply to | #120415 |
On Fri, 27 Sep 2024 16:14:29 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 27/09/2024 13:11, Muttley@dastardlyhq.com wrote: >> 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. >> ><snip> >>> 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. >> > >Are you talking about what is more commonly referred to as pattern matching? I've already posted a link to an article about it. Whatever you want to call it, the polymorphic function called is based on the value passed to it, not the type. > > factorial 0 = 1 > factorial n = n * factorial (n - 1) > > >That is not what is generally meant by polymorphism, it's just an >alternative (but often very neat) way to write a conditional : That applies to all types of polymorphism. All decisional code however its written eventually ends up as some kind of assembler cmp/jmp combination. Might be 2 opcodes, might be 1, doesn't matter, same thing.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-27 18:24 +0200 |
| Message-ID | <vd6m7c$pp1o$1@dont-email.me> |
| In reply to | #120416 |
On 27/09/2024 17:25, Muttley@dastardlyhq.com wrote: > On Fri, 27 Sep 2024 16:14:29 +0200 > David Brown <david.brown@hesbynett.no> boringly babbled: >> On 27/09/2024 13:11, Muttley@dastardlyhq.com wrote: >>> 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. >>> >> <snip> >>>> 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. >>> >> >> Are you talking about what is more commonly referred to as pattern matching? > > I've already posted a link to an article about it. Whatever you want to call > it, the polymorphic function called is based on the value passed to it, not > the type. > >> >> factorial 0 = 1 >> factorial n = n * factorial (n - 1) >> >> >> That is not what is generally meant by polymorphism, it's just an >> alternative (but often very neat) way to write a conditional : > > That applies to all types of polymorphism. All decisional code however its > written eventually ends up as some kind of assembler cmp/jmp combination. > Might be 2 opcodes, might be 1, doesn't matter, same thing. > > The key point of polymorphism - as I see it - is that the source code doing the dispatching does not know the details of the possible matches or targets. Thus C++ virtual methods support polymorphism - a function call call "p->foo()" for "p" of type "T*" without knowing anything about how many descendent types of "T" exist or how they different. All it needs to know is that the base class "T" has a virtual method "foo". This cannot be done with a series of cmp/jmp instructions - it ends up as an indirect call instruction. For static or compile-time polymorphism, the details of the generated code are not as important, but you still want the code that uses the polymorphic types, values, objects, whatever, to be independent of the things themselves. You get that in C++ CRTP templates, for example. I don't claim to have any kind of "official" definition of the term, but I am pretty confident that what you seem to be talking about (AFAIUI) is not something many people would refer to as "polymorphism"
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-28 09:12 +0000 |
| Message-ID | <vd8hao$16d5f$1@dont-email.me> |
| In reply to | #120417 |
On Fri, 27 Sep 2024 18:24:11 +0200 David Brown <david.brown@hesbynett.no> gabbled: >On 27/09/2024 17:25, Muttley@dastardlyhq.com wrote: >> That applies to all types of polymorphism. All decisional code however its >> written eventually ends up as some kind of assembler cmp/jmp combination. >> Might be 2 opcodes, might be 1, doesn't matter, same thing. >> >> > >The key point of polymorphism - as I see it - is that the source code >doing the dispatching does not know the details of the possible matches >or targets. Thus C++ virtual methods support polymorphism - a function Not sure how that differs with value polymorphism. >call call "p->foo()" for "p" of type "T*" without knowing anything about >how many descendent types of "T" exist or how they different. All it >needs to know is that the base class "T" has a virtual method "foo". > >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. >I am pretty confident that what you seem to be talking about (AFAIUI) is >not something many people would refer to as "polymorphism" When you say "people" you seem to be talking about people in the C++ world or perhaps C-type language world. Polymorphism is more than just type and virtual functions.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-28 17:33 +0200 |
| Message-ID | <vd97kq$1a3m9$2@dont-email.me> |
| In reply to | #120428 |
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:
>> On 27/09/2024 17:25, Muttley@dastardlyhq.com wrote:
>>> That applies to all types of polymorphism. All decisional code
>>> however its
>>> written eventually ends up as some kind of assembler cmp/jmp
>>> combination.
>>> Might be 2 opcodes, might be 1, doesn't matter, same thing.
>>>
>>>
>>
>> The key point of polymorphism - as I see it - is that the source code
>> doing the dispatching does not know the details of the possible
>> matches or targets. Thus C++ virtual methods support polymorphism - a
>> function
>
> Not sure how that differs with value polymorphism.
>
I explained that - look at my answer below for another attempt.
>> call call "p->foo()" for "p" of type "T*" without knowing anything
>> about how many descendent types of "T" exist or how they different.
>> All it needs to know is that the base class "T" has a virtual method
>> "foo".
>>
>> 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.
Suppose you have these files :
// foo.h
struct Foo {
virtual void doFoo();
};
// foo.cpp
#include <stdio.h>
#include "foo.h"
void Foo::doFoo() {
printf("I'm a Foo, and I'm doing foo\n");
}
// bar.h
extern void doLotsOfFoo(Foo * pf);
// bar.cpp
#include "foo.h"
void doLotsOfFoo(Foo * pf)
{
for (int i = 0; i < 10; i++) {
pf->doFoo();
}
}
// foobar.cpp
#include <stdio.h>
#include "foo.h"
#include "bar.h"
struct FooBar : Foo {
void doFoo();
};
void FooBar::doFoo() {
printf("I'm a FooBar, and I'm doing foo\n");
}
void testFoo() {
FooBar fb;
doLotsOfFoo(&fb);
}
That's run-time polymorphism using class inheritance and virtual
functions. When compiling doLotsOfFoo(), there is no way for the
compiler to know what types it might be called with - there is no way it
could be compiled as a selection of comparisons. Baring full-program
optimisation, indirect calls are the only way to handle it.
>> I am pretty confident that what you seem to be talking about (AFAIUI)
>> is not something many people would refer to as "polymorphism"
>
> When you say "people" you seem to be talking about people in the C++ world
> or perhaps C-type language world. Polymorphism is more than just type
> and virtual functions.
>
I realise the term is used in other languages too (although the emphasis
here is of course on C++, since we are in c.l.c++). But no, I am not
restricting "people" to C++ programmers - they may be programmers of any
languages, including functional programming languages.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-28 15:47 +0000 |
| Message-ID | <vd98f1$1aius$1@dont-email.me> |
| In reply to | #120435 |
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. >> 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. Really? What exactly do you think an assembler call instruction is other than a single opcode stack push and jump? >That's run-time polymorphism using class inheritance and virtual >functions. When compiling doLotsOfFoo(), there is no way for the >compiler to know what types it might be called with - there is no way it >could be compiled as a selection of comparisons. Baring full-program >optimisation, indirect calls are the only way to handle it. And you don't think indirect jump instructions exist? https://en.wikipedia.org/wiki/Indirect_branch We can add assembler to the list of things you don't understand.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-29 13:41 +0200 |
| Message-ID | <vdbed8$1o0lg$1@dont-email.me> |
| In reply to | #120436 |
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/. I am not new to programming, and have used a large variety of languages (including functional programming languages), but have not heard the 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. > >>> 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. > > 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. Maybe you misread, or expressed yourself badly, or mixed up what you were trying to say. > >> That's run-time polymorphism using class inheritance and virtual >> functions. When compiling doLotsOfFoo(), there is no way for the >> compiler to know what types it might be called with - there is no way >> it could be compiled as a selection of comparisons. Baring >> full-program optimisation, indirect calls are the only way to handle it. > > And you don't think indirect jump instructions exist? > > https://en.wikipedia.org/wiki/Indirect_branch > A call is, fundamentally, just a jump with a returned address stored in some way. I'm not making a distinction between indirect calls and indirect jumps, as that's just detail. > We can add assembler to the list of things you don't understand. >
[toc] | [prev] | [next] | [standalone]
Page 6 of 13 — ← Prev page 1 … 4 5 [6] 7 8 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web