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 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 14:38 +0200 |
| Message-ID | <vd107q$3m0aj$6@dont-email.me> |
| In reply to | #120283 |
On 25/09/2024 14:03, Bonita Montero wrote:
> Am 25.09.2024 um 13:49 schrieb David Brown:
>
>> template<class Compare, class T>
>> concept ComparisonFunctionObject = requires (T a, T b)
>> {
>> { Compare()(a, b) } -> std::convertible_to<bool>;
>> };
>
> This may fail with a lambda with capture, since the lambda isn't
> default-constructible but just moveable or copyable. So it should
> look like this:
>
> template<class Compare, class T>
> concept ComparisonFunctionObject = requires (Compare cmp, T a, T b)
> {
> { cmp(a, b) } -> std::convertible_to<bool>;
> };
>
Yes, that is better.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-25 15:17 +0300 |
| Message-ID | <20240925151723.00006aa3@yahoo.com> |
| In reply to | #120281 |
On Wed, 25 Sep 2024 13:49:26 +0200
David Brown <david.brown@hesbynett.no> wrote:
> On 25/09/2024 12:11, Michael S wrote:
> > On Wed, 25 Sep 2024 08:24:19 -0000 (UTC)
> > Muttley@dastardlyhq.com wrote:
> >
> >> On Wed, 25 Sep 2024 09:49:49 +0200
> >> David Brown <david.brown@hesbynett.no> boringly babbled:
> >>> looks up. The error message is likely to be complex because the
> >>> compiler doesn't know where you made the mistake, and tries to
> >>> list
> >>
> >> It knows what line invoked the error so all it needs to do is print
> >> that.
> >>
> >>> Using concepts, however, means the error is found on the first
> >>> attempt to use the type "A<T>" - the compiler can give far clearer
> >>> information. It can say "On line x, you tried to make A<T>, but
> >>> type T does not fulfil the requirement you gave on line y when you
> >>> defined class A".
> >>
> >> Tbh if you want to massage templating that much then don't use it
> >> in the first place, just hard code the functions.
> >>
> >>> Competition is a great thing). And you sometimes want more
> >>> information, sometimes less. But concepts give the programmer and
> >>> the compiler a far better starting point.
> >>
> >> This is where compiler command line switches should come into play.
> >>
> >>> They also allow neater and clearer code with constrained auto
> >>> declarations, letting you specify something between "this /exact/
> >>> type" and "whatever seems to fit".
> >>
> >> Don't use auto in those scenarios then. Its always nicer when
> >> people put the specific type in the code anyway.
> >>
> >
> > Below is example of very simple function with very small
> > template-related bug of sort that people sometimes do in real life.
> > I tried 3 compilers. Each one produces more than 20 lines of error
> > messages none of which was enlightening.
> >
> > #include <cstdint>
> > #include <algorithm>
> >
> > void my_sort2(uint8_t* buf, int buflen, const uint8_t* trans_tab)
> > {
> > struct {
> > const uint8_t* tab;
> > bool operator() (uint8_t a, uint8_t b) {
> > return tab[a] < tab[b];
> > }
> > } cmp;
> > cmp.tab = trans_tab;
> > std::sort(buf, buf+buflen, &cmp);
> > }
> >
> > I don't know if with conceptized <algorithm> error reporting would
> > work better. But it is worth a try, because current state is not
> > satisfactory.
> >
> >
> >
>
> This is a rough attempt at using concepts here. I made an "xsort"
> template that checks (at compile time, obviously) a requirement and
> otherwise passes things on to std::sort. The
> "ComparisonFunctionObject" concept checks that you can call the
> object with two values of a given type and get a result that can be
> converted to a bool. The requirement for the Compare parameter to
> xsort is that this concept must be satisfied with the type you get
> from dereferencing the iterators.
>
> The error messages you get are a lot shorter and clearer. There's
> still room for improvement, as always, but it is a /big/ step forward.
>
> If you think a particular kind of error - such as using a pointer to
> the comparison function object instead of the object itself - is
> common, you can add extra checks to make the errors even clearer.
>
> <https://godbolt.org/z/jzqeh8enG>
>
>
>
>
> #include <concepts>
> #include <type_traits>
> #include <cstdint>
> #include <algorithm>
>
>
> template <class T>
> concept Not_pointer = !std::is_pointer_v<T>;
>
> template<class Compare, class T>
> concept ComparisonFunctionObject = requires (T a, T b)
> {
> { Compare()(a, b) } -> std::convertible_to<bool>;
> };
>
>
> template< class RandomIt, class Compare >
> requires
> #if 1 // <- Change this
> Not_pointer<Compare> &&
> #endif
> ComparisonFunctionObject<Compare,
> std::remove_pointer_t<RandomIt> > void xsort( RandomIt first,
> RandomIt last, Compare comp ) { std::sort(first, last, comp);
> }
>
> void my_sort2(uint8_t* buf, int buflen, const uint8_t* trans_tab)
> {
> struct {
> const uint8_t* tab;
> bool operator() (uint8_t a, uint8_t b) {
> return tab[a] < tab[b];
> }
> } cmp;
> cmp.tab = trans_tab;
>
> xsort(buf, buf+buflen, cmp);
> xsort(buf, buf+buflen, &cmp);
> }
>
>
>
>
Interesting attempt, but not good enough. It fails in most common
use case where Compare is function rather than object.
bool cmp3(uint8_t a, uint8_t b) {
return a < b;
}
void my_sort3(uint8_t* buf, int buflen, const uint8_t* )
{
#if 1
xsort(buf, buf+buflen, cmp3);
#else
std::sort(buf, buf+buflen, cmp3);
#endif
}
STL's insistence on [mis]use of static polymorphism in every possible
and impossible hole strikes again!
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-09-25 15:49 +0300 |
| Message-ID | <vd10sb$3me2n$1@dont-email.me> |
| In reply to | #120284 |
On 25.09.2024 15:17, Michael S wrote:
> On Wed, 25 Sep 2024 13:49:26 +0200
> David Brown <david.brown@hesbynett.no> wrote:
>
>> On 25/09/2024 12:11, Michael S wrote:
>>> On Wed, 25 Sep 2024 08:24:19 -0000 (UTC)
>>> Muttley@dastardlyhq.com wrote:
>>>
>>>> On Wed, 25 Sep 2024 09:49:49 +0200
>>>> David Brown <david.brown@hesbynett.no> boringly babbled:
>>>>> looks up. The error message is likely to be complex because the
>>>>> compiler doesn't know where you made the mistake, and tries to
>>>>> list
>>>>
>>>> It knows what line invoked the error so all it needs to do is print
>>>> that.
>>>>
>>>>> Using concepts, however, means the error is found on the first
>>>>> attempt to use the type "A<T>" - the compiler can give far clearer
>>>>> information. It can say "On line x, you tried to make A<T>, but
>>>>> type T does not fulfil the requirement you gave on line y when you
>>>>> defined class A".
>>>>
>>>> Tbh if you want to massage templating that much then don't use it
>>>> in the first place, just hard code the functions.
>>>>
>>>>> Competition is a great thing). And you sometimes want more
>>>>> information, sometimes less. But concepts give the programmer and
>>>>> the compiler a far better starting point.
>>>>
>>>> This is where compiler command line switches should come into play.
>>>>
>>>>> They also allow neater and clearer code with constrained auto
>>>>> declarations, letting you specify something between "this /exact/
>>>>> type" and "whatever seems to fit".
>>>>
>>>> Don't use auto in those scenarios then. Its always nicer when
>>>> people put the specific type in the code anyway.
>>>>
>>>
>>> Below is example of very simple function with very small
>>> template-related bug of sort that people sometimes do in real life.
>>> I tried 3 compilers. Each one produces more than 20 lines of error
>>> messages none of which was enlightening.
>>>
>>> #include <cstdint>
>>> #include <algorithm>
>>>
>>> void my_sort2(uint8_t* buf, int buflen, const uint8_t* trans_tab)
>>> {
>>> struct {
>>> const uint8_t* tab;
>>> bool operator() (uint8_t a, uint8_t b) {
>>> return tab[a] < tab[b];
>>> }
>>> } cmp;
>>> cmp.tab = trans_tab;
>>> std::sort(buf, buf+buflen, &cmp);
>>> }
>>>
>>> I don't know if with conceptized <algorithm> error reporting would
>>> work better. But it is worth a try, because current state is not
>>> satisfactory.
>>>
>>>
>>>
>>
>> This is a rough attempt at using concepts here. I made an "xsort"
>> template that checks (at compile time, obviously) a requirement and
>> otherwise passes things on to std::sort. The
>> "ComparisonFunctionObject" concept checks that you can call the
>> object with two values of a given type and get a result that can be
>> converted to a bool. The requirement for the Compare parameter to
>> xsort is that this concept must be satisfied with the type you get
>> from dereferencing the iterators.
>>
>> The error messages you get are a lot shorter and clearer. There's
>> still room for improvement, as always, but it is a /big/ step forward.
>>
>> If you think a particular kind of error - such as using a pointer to
>> the comparison function object instead of the object itself - is
>> common, you can add extra checks to make the errors even clearer.
>>
>> <https://godbolt.org/z/jzqeh8enG>
>>
>>
>>
>>
>> #include <concepts>
>> #include <type_traits>
>> #include <cstdint>
>> #include <algorithm>
>>
>>
>> template <class T>
>> concept Not_pointer = !std::is_pointer_v<T>;
>>
>> template<class Compare, class T>
>> concept ComparisonFunctionObject = requires (T a, T b)
>> {
>> { Compare()(a, b) } -> std::convertible_to<bool>;
>> };
>>
>>
>> template< class RandomIt, class Compare >
>> requires
>> #if 1 // <- Change this
>> Not_pointer<Compare> &&
>> #endif
>> ComparisonFunctionObject<Compare,
>> std::remove_pointer_t<RandomIt> > void xsort( RandomIt first,
>> RandomIt last, Compare comp ) { std::sort(first, last, comp);
>> }
>>
>> void my_sort2(uint8_t* buf, int buflen, const uint8_t* trans_tab)
>> {
>> struct {
>> const uint8_t* tab;
>> bool operator() (uint8_t a, uint8_t b) {
>> return tab[a] < tab[b];
>> }
>> } cmp;
>> cmp.tab = trans_tab;
>>
>> xsort(buf, buf+buflen, cmp);
>> xsort(buf, buf+buflen, &cmp);
>> }
>>
>>
>>
>>
>
> Interesting attempt, but not good enough. It fails in most common
> use case where Compare is function rather than object.
Callback functions are a C thing. In C++ we have functors and lambdas.
Over the years I have removed all ancient callback functions from my
code and replaced by functors or lambdas, so your "most common use case"
is not everybody's use case.
In this example (a one-line sort helper) a lambda is the superior
solution anyway.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 14:52 +0200 |
| Message-ID | <vd111d$3mfvn$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120294 |
Am 25.09.2024 um 14:49 schrieb Paavo Helde: > Callback functions are a C thing. In C++ we have functors and lambdas. Which may be callbacks with state. > Over the years I have removed all ancient callback functions from my > code and replaced by functors or lambdas, so your "most common use case" > is not everybody's use case. Functional programming rocks. You can divide your code in smaller, more maintaineable pieces with that.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 12:55 +0000 |
| Message-ID | <vd1187$3mhqh$1@dont-email.me> |
| In reply to | #120294 |
On Wed, 25 Sep 2024 15:49:15 +0300 Paavo Helde <eesnimi@osa.pri.ee> boringly babbled: >Callback functions are a C thing. In C++ we have functors and lambdas. >Over the years I have removed all ancient callback functions from my >code and replaced by functors or lambdas, so your "most common use case" What for? They usually compile down to the same code at the end and lambdas are only useful if that function is only used in that one place. If its used more than once then a function pointer is more useful and neater. >In this example (a one-line sort helper) a lambda is the superior >solution anyway. Why?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 15:08 +0200 |
| Message-ID | <vd11vi$3mk4r$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120297 |
Am 25.09.2024 um 14:55 schrieb Muttley@dastardlyhq.com: > What for? They usually compile down to the same code at the end and lambdas > are only useful if that function is only used in that one place. If its used > more than once then a function pointer is more useful and neater. Usually you have state along with your function-object, this can't be attached conveniently to a function-pointer. With lambdas that's easy, their state can be copied and moved.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 13:24 +0000 |
| Message-ID | <vd12ua$3mpem$1@dont-email.me> |
| In reply to | #120303 |
On Wed, 25 Sep 2024 15:08:09 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 25.09.2024 um 14:55 schrieb Muttley@dastardlyhq.com: > >> What for? They usually compile down to the same code at the end and lambdas >> are only useful if that function is only used in that one place. If its used >> more than once then a function pointer is more useful and neater. > >Usually you have state along with your function-object, this can't be Rarely used. Eg sorting functor for STL containers. >attached conveniently to a function-pointer. With lambdas that's easy, >their state can be copied and moved. A lambda is just an inline function. Its syntatic sugar.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 15:28 +0200 |
| Message-ID | <vd1359$3mpui$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120307 |
Am 25.09.2024 um 15:24 schrieb Muttley@dastardlyhq.com: > On Wed, 25 Sep 2024 15:08:09 +0200 > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >> Am 25.09.2024 um 14:55 schrieb Muttley@dastardlyhq.com: >> >>> What for? They usually compile down to the same code at the end and lambdas >>> are only useful if that function is only used in that one place. If its used >>> more than once then a function pointer is more useful and neater. >> >> Usually you have state along with your function-object, this can't be > > Rarely used. Eg sorting functor for STL containers. I'm using functional programmg all the day and most lambdss I write have state. >> attached conveniently to a function-pointer. With lambdas that's easy, >> their state can be copied and moved. > A lambda is just an inline function. Its syntatic sugar. A lambda isn't an inline function but has a calling operator which is an inline function. The lambda itself is an anonymous class.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 13:36 +0000 |
| Message-ID | <vd13k7$3mskc$1@dont-email.me> |
| In reply to | #120308 |
On Wed, 25 Sep 2024 15:28:15 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 25.09.2024 um 15:24 schrieb Muttley@dastardlyhq.com: >> On Wed, 25 Sep 2024 15:08:09 +0200 >> Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >>> Am 25.09.2024 um 14:55 schrieb Muttley@dastardlyhq.com: >>> >>>> What for? They usually compile down to the same code at the end and lambdas > >>>> are only useful if that function is only used in that one place. If its >used >>>> more than once then a function pointer is more useful and neater. >>> >>> Usually you have state along with your function-object, this can't be >> >> Rarely used. Eg sorting functor for STL containers. > >I'm using functional programmg all the day and most lambdss I write >have state. If you're writing C++ you're not doing functional programming, period. Functional requires polymorphism by value which C++ does not support.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 15:44 +0200 |
| Message-ID | <vd143e$3mu8h$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120310 |
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 requires polymorphism by value which C++ does not support. Functional programming in C++ allows for compile-time polymporphism with generic function-objects and and runtime polymporphism with std::function<>.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 14:11 +0000 |
| Message-ID | <vd15mv$3n6uq$1@dont-email.me> |
| In reply to | #120311 |
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. >> Functional requires polymorphism by value which C++ does not support. > >Functional programming in C++ allows for compile-time polymporphism >with generic function-objects and and runtime polymporphism with >std::function<>. Which part of polymorphism by value did you not understand?
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 16:14 +0200 |
| Message-ID | <vd15rt$3n74v$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120312 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 15:32 +0000 |
| Message-ID | <vd1adq$3nttp$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]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 17:33 +0200 |
| Message-ID | <vd1age$3nto7$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120323 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 15:49 +0000 |
| Message-ID | <vd1bdr$3o32e$1@dont-email.me> |
| In reply to | #120325 |
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/
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 17:53 +0200 |
| Message-ID | <vd1bmf$3o3ra$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120327 |
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:
void fileList( wchar_t const *path, std::function<bool (
WIN32_FIND_DATAW const & )> const &fn, DWORD *pdwErr )
{
using namespace std;
if( pdwErr )
*pdwErr = NO_ERROR;
WIN32_FIND_DATAW fd;
HANDLE hFind = FindFirstFileW( path, &fd );
auto err = [&]<bool Initiate>( bool_constant<Initiate> )
{
DWORD dwErr = GetLastError();
if( dwErr == (Initiate ? ERROR_FILE_NOT_FOUND : ERROR_NO_MORE_FILES) )
return;
if( !pdwErr )
{
constexpr char const *ERR = Initiate ? "FindFirstFile() failed: \"" :
"FindNextFile() failed: \"";
throw system_error( dwErr, system_category(), (ostringstream() << ERR
<< wideCharToMultiByte( path ) << "\"").str().c_str() );
}
*pdwErr = dwErr;
};
if( hFind == INVALID_HANDLE_VALUE )
return (void)err( true_type() );
invoke_on_destruct closeFind( [&]() { FindClose( hFind ); } );
do
if( wcscmp( fd.cFileName, L"." ) == 0 || wcscmp( fd.cFileName, L".." )
== 0 )
continue;
else if( !fn( fd ) )
return;
while( FindNextFileW( hFind, &fd ) );
err( false_type() );
}
You can pass a lambda to this function and the type-polymorphism
becomes a value-polymophism.
> ... as well as type polymorphism.
Generic function objects are type-polymorphism.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-26 07:34 +0000 |
| Message-ID | <vd32qq$3mjh$1@dont-email.me> |
| In reply to | #120328 |
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] >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.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-26 10:20 +0200 |
| Message-ID | <vd35gu$42ms$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120344 |
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". >> 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.
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-09-26 16:46 +0800 |
| Message-ID | <878708eaa6336d5477b0a9865471565d302b44e4.camel@gmail.com> |
| In reply to | #120350 |
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)
> > > 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.
>
[toc] | [prev] | [next] | [standalone]
| From | wij <wyniijj5@gmail.com> |
|---|---|
| Date | 2024-09-26 16:51 +0800 |
| Message-ID | <6c5d67d846c4e57bf031aae5f2859b58a1e7f34b.camel@gmail.com> |
| In reply to | #120356 |
On Thu, 2024-09-26 at 16:46 +0800, wij 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)
>
Sorry. My example is incorrect. I don't know how to make a proper example to
loop backward... the variable should be signed type.
> > > > 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.
> >
>
>
[toc] | [prev] | [next] | [standalone]
Page 5 of 13 — ← Prev page 1 … 3 4 [5] 6 7 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web