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 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 11:15 +0000 |
| Message-ID | <vd0rbm$3lnmf$1@dont-email.me> |
| In reply to | #120267 |
On Wed, 25 Sep 2024 11:32:56 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 25.09.2024 um 10:24 schrieb Muttley@dastardlyhq.com: > >> Tbh if you want to massage templating that much then don't use it in the >> first place, just hard code the functions. > >To avoid concepts ? LOL. > >> This is where compiler command line switches should come into play. > >Without concepts the compiler has no other choice than giving Swahili >error messages from inside the implementation. > >> Don't use auto in those scenarios then. Its always nicer when people put >> the specific type in the code anyway. > >auto-parameters *with* concepts become much cleaner than without. >There's no choice to hardcode sth. then because you want to be generic. Generic is only needed if you're writing a library for others to use. If you're writing a self contained program its nothing more than a shortcut so in that instance if it causes issues then hard code the functions.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 13:30 +0200 |
| Message-ID | <vd0s7n$3lpgc$2@raubtier-asyl.eternal-september.org> |
| In reply to | #120274 |
Am 25.09.2024 um 13:15 schrieb Muttley@dastardlyhq.com:
> Generic is only needed if you're writing a library for others to use.
I often write generic code that I use myself in different ways,
each specialized to a set of generic types. I think that's much
more common than that someone implements a generic API for use
by the public.
F.e. this code is a function which concatenates anything which
can be converted to a basic_string_view to a corrsponding string
with same char- and traits-tyme.
#pragma once
#include <type_traits>
#include <concepts>
#include <string_view>
#include <array>
template<typename String, typename ... Viewables>
requires std::same_as<String, std::basic_string<typename
String::value_type, typename String::traits_type, typename
String::allocator_type>>
&& (std::convertible_to<Viewables, std::basic_string_view<typename
String::value_type, typename String::traits_type>> && ...)
inline String sv_concat( Viewables &... viewables )
{
using namespace std;
String str;
constexpr size_t N = sizeof ...(Viewables);
if constexpr( N )
{
using sv_type = basic_string_view<typename String::value_type,
typename String::traits_type>;
array<sv_type, N> views = { viewables ... };
[&]<size_t ... Indices>( index_sequence<Indices ...> )
{
str.reserve( (views[Indices].length() + ...) );
((str += views[Indices]), ...);
}( make_index_sequence<N>() );
}
return str;
}
Looks complex, but the concatenating string with that code is as
efficient as possible:
string fn( string_view svA, string strB, char const *cStrC )
{
return sv_concat<string>( svA, strB, cStrC );
}
Without generic programming I'd to write the code at least for
each character-type.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 12:43 +0000 |
| Message-ID | <vd10gn$3mejg$1@dont-email.me> |
| In reply to | #120277 |
On Wed, 25 Sep 2024 13:30:05 +0200 Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >Am 25.09.2024 um 13:15 schrieb Muttley@dastardlyhq.com: > >> Generic is only needed if you're writing a library for others to use. > >I often write generic code that I use myself in different ways, >each specialized to a set of generic types. I think that's much >more common than that someone implements a generic API for use >by the public. >F.e. this code is a function which concatenates anything which >can be converted to a basic_string_view to a corrsponding string >with same char- and traits-tyme. Looks like a library function to me albeit only you use. I doubt you'd only use it in one program.
[toc] | [prev] | [next] | [standalone]
| From | Bonita Montero <Bonita.Montero@gmail.com> |
|---|---|
| Date | 2024-09-25 14:50 +0200 |
| Message-ID | <vd10ug$3mfvn$1@raubtier-asyl.eternal-september.org> |
| In reply to | #120292 |
Am 25.09.2024 um 14:43 schrieb Muttley@dastardlyhq.com: > On Wed, 25 Sep 2024 13:30:05 +0200 > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >> Am 25.09.2024 um 13:15 schrieb Muttley@dastardlyhq.com: >> >>> Generic is only needed if you're writing a library for others to use. >> >> I often write generic code that I use myself in different ways, >> each specialized to a set of generic types. I think that's much >> more common than that someone implements a generic API for use >> by the public. >> F.e. this code is a function which concatenates anything which >> can be converted to a basic_string_view to a corrsponding string >> with same char- and traits-tyme. > > Looks like a library function to me albeit only you use. I doubt you'd only > use it in one program. > > Of course it's a library-function, but not written for the public.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 14:00 +0200 |
| Message-ID | <vd0u0m$3m0aj$2@dont-email.me> |
| In reply to | #120274 |
On 25/09/2024 13:15, Muttley@dastardlyhq.com wrote: > On Wed, 25 Sep 2024 11:32:56 +0200 > Bonita Montero <Bonita.Montero@gmail.com> boringly babbled: >> Am 25.09.2024 um 10:24 schrieb Muttley@dastardlyhq.com: >> >>> Tbh if you want to massage templating that much then don't use it in the >>> first place, just hard code the functions. >> >> To avoid concepts ? LOL. >> >>> This is where compiler command line switches should come into play. >> >> Without concepts the compiler has no other choice than giving Swahili >> error messages from inside the implementation. >> >>> Don't use auto in those scenarios then. Its always nicer when people put >>> the specific type in the code anyway. >> >> auto-parameters *with* concepts become much cleaner than without. >> There's no choice to hardcode sth. then because you want to be generic. > > Generic is only needed if you're writing a library for others to use. If > you're writing a self contained program its nothing more than a shortcut so > in that instance if it causes issues then hard code the functions. > I use generic code regularly in my small-systems embedded programming. Rather than using run-time class hierarchies with virtual functions and run-time polymorphic code, I use compile-time class hierarchies and generic functions. This means more information can be tied to the types of objects, resulting in minimal object code and maximal efficiency without having to duplicate the source code. Of course it has its limitations - the function definition for templates has to be seen at compile-time, so headers are bigger and compile and link times are slower, debugging can be more awkward, and it is only appropriate for some code.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 12:47 +0000 |
| Message-ID | <vd10ot$3mfkq$1@dont-email.me> |
| In reply to | #120282 |
On Wed, 25 Sep 2024 14:00:22 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 25/09/2024 13:15, Muttley@dastardlyhq.com wrote: >> Generic is only needed if you're writing a library for others to use. If >> you're writing a self contained program its nothing more than a shortcut so >> in that instance if it causes issues then hard code the functions. >> > >I use generic code regularly in my small-systems embedded programming. >Rather than using run-time class hierarchies with virtual functions and >run-time polymorphic code, I use compile-time class hierarchies and >generic functions. This means more information can be tied to the types >of objects, resulting in minimal object code and maximal efficiency >without having to duplicate the source code. Can't imagine why you'd need any of that in small systems embedded as the size of programs you can fit into memory constrains the structural complexity. If you need class inheritance in something that has to fit into 16K or whatever then you're doing it wrong.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 15:00 +0200 |
| Message-ID | <vd11h4$3mfjo$2@dont-email.me> |
| In reply to | #120293 |
On 25/09/2024 14:47, Muttley@dastardlyhq.com wrote: > On Wed, 25 Sep 2024 14:00:22 +0200 > David Brown <david.brown@hesbynett.no> boringly babbled: >> On 25/09/2024 13:15, Muttley@dastardlyhq.com wrote: >>> Generic is only needed if you're writing a library for others to use. If >>> you're writing a self contained program its nothing more than a shortcut so >>> in that instance if it causes issues then hard code the functions. >>> >> >> I use generic code regularly in my small-systems embedded programming. >> Rather than using run-time class hierarchies with virtual functions and >> run-time polymorphic code, I use compile-time class hierarchies and >> generic functions. This means more information can be tied to the types >> of objects, resulting in minimal object code and maximal efficiency >> without having to duplicate the source code. > > Can't imagine why you'd need any of that in small systems embedded as the > size of programs you can fit into memory constrains the structural complexity. > If you need class inheritance in something that has to fit into 16K or > whatever then you're doing it wrong. > That is just because you can't imagine.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 13:22 +0000 |
| Message-ID | <vd12r6$3mp43$1@dont-email.me> |
| In reply to | #120299 |
On Wed, 25 Sep 2024 15:00:20 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 25/09/2024 14:47, Muttley@dastardlyhq.com wrote: >> On Wed, 25 Sep 2024 14:00:22 +0200 >> David Brown <david.brown@hesbynett.no> boringly babbled: >>> On 25/09/2024 13:15, Muttley@dastardlyhq.com wrote: >>>> Generic is only needed if you're writing a library for others to use. If >>>> you're writing a self contained program its nothing more than a shortcut so > >>>> in that instance if it causes issues then hard code the functions. >>>> >>> >>> I use generic code regularly in my small-systems embedded programming. >>> Rather than using run-time class hierarchies with virtual functions and >>> run-time polymorphic code, I use compile-time class hierarchies and >>> generic functions. This means more information can be tied to the types >>> of objects, resulting in minimal object code and maximal efficiency >>> without having to duplicate the source code. >> >> Can't imagine why you'd need any of that in small systems embedded as the >> size of programs you can fit into memory constrains the structural >complexity. >> If you need class inheritance in something that has to fit into 16K or >> whatever then you're doing it wrong. >> > >That is just because you can't imagine. Funny. Misra-C++ is it? No? Then you're just playing with toys, not doing proper embedded.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 17:12 +0200 |
| Message-ID | <vd198f$3nh00$1@dont-email.me> |
| In reply to | #120306 |
On 25/09/2024 15:22, Muttley@dastardlyhq.com wrote: > On Wed, 25 Sep 2024 15:00:20 +0200 > David Brown <david.brown@hesbynett.no> boringly babbled: >> On 25/09/2024 14:47, Muttley@dastardlyhq.com wrote: >>> On Wed, 25 Sep 2024 14:00:22 +0200 >>> David Brown <david.brown@hesbynett.no> boringly babbled: >>>> On 25/09/2024 13:15, Muttley@dastardlyhq.com wrote: >>>>> Generic is only needed if you're writing a library for others to use. If >>>>> you're writing a self contained program its nothing more than a shortcut so >> >>>>> in that instance if it causes issues then hard code the functions. >>>>> >>>> >>>> I use generic code regularly in my small-systems embedded programming. >>>> Rather than using run-time class hierarchies with virtual functions and >>>> run-time polymorphic code, I use compile-time class hierarchies and >>>> generic functions. This means more information can be tied to the types >>>> of objects, resulting in minimal object code and maximal efficiency >>>> without having to duplicate the source code. >>> >>> Can't imagine why you'd need any of that in small systems embedded as the >>> size of programs you can fit into memory constrains the structural >> complexity. >>> If you need class inheritance in something that has to fit into 16K or >>> whatever then you're doing it wrong. >>> >> >> That is just because you can't imagine. > > Funny. Misra-C++ is it? No? Then you're just playing with toys, not doing > proper embedded. > If you think MISRA is required for embedded development, or even if you think it is a good idea that promotes safe and reliable coding, then you have little concept of the field. There are certainly markets where MISRA is strongly encouraged or even required, but that is all about legal arse-covering, not actual safety or reliability. And anyway, MISRA C++ is quite happy with templates and generic code. However, the last MISRA C++ version I have is from 2008, so perhaps in the they have decided to ban templates for MISRA C++ 2023 (covering C++17), though I strongly doubt it.
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 15:35 +0000 |
| Message-ID | <vd1ak6$3nuqg$1@dont-email.me> |
| In reply to | #120317 |
On Wed, 25 Sep 2024 17:12:15 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 25/09/2024 15:22, Muttley@dastardlyhq.com wrote: >> Funny. Misra-C++ is it? No? Then you're just playing with toys, not doing >> proper embedded. >> > >If you think MISRA is required for embedded development, or even if you >think it is a good idea that promotes safe and reliable coding, then you >have little concept of the field. There are certainly markets where I didn't embedded in the UK defense industry so I probably have a bit more of a clue than you piddling around with your arduino or PIC writing code for a toaster.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 19:19 +0200 |
| Message-ID | <vd1gms$3ovnj$1@dont-email.me> |
| In reply to | #120326 |
On 25/09/2024 17:35, Muttley@dastardlyhq.com wrote: > On Wed, 25 Sep 2024 17:12:15 +0200 > David Brown <david.brown@hesbynett.no> boringly babbled: >> On 25/09/2024 15:22, Muttley@dastardlyhq.com wrote: >>> Funny. Misra-C++ is it? No? Then you're just playing with toys, not doing >>> proper embedded. >>> >> >> If you think MISRA is required for embedded development, or even if you >> think it is a good idea that promotes safe and reliable coding, then you >> have little concept of the field. There are certainly markets where > > I didn't embedded in the UK defense industry so I probably have a bit more of > a clue than you piddling around with your arduino or PIC writing code for > a toaster. > You "didn't embedded in the UK defense industry" - that I believe. It's harder to believe that you /did/ work with embedded systems related to the UK defence industry. From my own experience, I know there are people in that field who are good at what they do, and others that go through the motions. And I know that arse-covering is often higher priority than actually trying to do good development - "You can't sue us for writing bad software, because we use industry standard MISRA rules".
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-26 07:36 +0000 |
| Message-ID | <vd32tt$3n51$1@dont-email.me> |
| In reply to | #120331 |
On Wed, 25 Sep 2024 19:19:24 +0200 David Brown <david.brown@hesbynett.no> boringly babbled: >On 25/09/2024 17:35, Muttley@dastardlyhq.com wrote: >> I didn't embedded in the UK defense industry so I probably have a bit more of > >> a clue than you piddling around with your arduino or PIC writing code for >> a toaster. >> > >You "didn't embedded in the UK defense industry" - that I believe. >It's harder to believe that you /did/ work with embedded systems related >to the UK defence industry. From my own experience, I know there are Believe what you like matey. Misra-C and LDRA were the order of the day. >priority than actually trying to do good development - "You can't sue us >for writing bad software, because we use industry standard MISRA rules". Law isn't my area so no idea.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 11:36 +0200 |
| Message-ID | <vd0ljo$3keo4$1@dont-email.me> |
| In reply to | #120265 |
On 25/09/2024 10:24, 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.
>
But that is typically not where the error lies.
Compilers give messages that try to help the developer find the problem,
not just tell you there is a problem. If it just says you can't do
"foo(a);", that tells me little - I know that line is correct. The
problem lies with the type of "a", or the definition of that type, or
the declaration of "foo". That's what I want to know about.
>> 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.
>
Sometimes you want something in between.
If you want a template function that can be used with any integral type,
you can have "auto next(std::integral auto x) { return x + 1; }". You
are limiting this to integer types (using a standard library concept).
You don't have to hard-code all the different types of integer.
Equally, it is not so open that it will also work with pointers - if you
try "next(&y)", you'll get a nice clear error message.
>> 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 can help, of course - as can a good IDE that interprets the error
messages and helps you navigate to possible errors. Concepts make the
whole thing easier and clearer in many cases.
Generating good, clear and helpful error messages and warnings is
/really/ difficult. It is typically harder for compilers than merely
generating correct object code for correct source code.
And they also make the code requirements a lot clearer to human readers.
They let you specify your classes and functions better, in code rather
than in comments (since comments are often out of sync with the code).
>
>> 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.
>
No, it is not always nicer. It is /sometimes/ nicer. At other times,
type inference is nicer - especially in templates. Constrained type
inference can be nicer still.
I am not suggesting that concepts always result in clearer error
messages, or that they mean compilers don't have to improve their
messages. I am not suggesting that they should be used for every
declaration, or at every opportunity.
I am merely saying that they give you another useful tool that can aid
writing good, clear code, and getting good help from your tools.
(And I am not in any way trying to defend Bonita's code style!)
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-25 13:11 +0300 |
| Message-ID | <20240925131144.00004c38@yahoo.com> |
| In reply to | #120265 |
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.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-25 13:31 +0300 |
| Message-ID | <20240925133134.0000221f@yahoo.com> |
| In reply to | #120269 |
On Wed, 25 Sep 2024 13:11:44 +0300
Michael S <already5chosen@yahoo.com> 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.
>
>
>
Below is an example of even more likely user mistake.
gcc generated 63 lines of errors, MSVC produced 69 lines and clang
had beaten both of them with 217 lines!
Even if, by chance, one or two of the messages make sense, they are
well hidden in piles of garbage.
void my_sort3(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);
}
[toc] | [prev] | [next] | [standalone]
| From | Paavo Helde <eesnimi@osa.pri.ee> |
|---|---|
| Date | 2024-09-25 13:52 +0300 |
| Message-ID | <vd0q23$3ldqt$1@dont-email.me> |
| In reply to | #120270 |
On 25.09.2024 13:31, Michael S wrote:
> Below is an example of even more likely user mistake.
> gcc generated 63 lines of errors, MSVC produced 69 lines and clang
> had beaten both of them with 217 lines!
> Even if, by chance, one or two of the messages make sense, they are
> well hidden in piles of garbage.
>
> void my_sort3(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);
> }
>
VStudio 2022 gives pretty clear error messages: cannot convert from an
integer to a pointer, when calling operator():
Build started at 13:49...
1>------ Build started: Project: ConsoleTest2022, Configuration: Debug
x64 ------
1>main.cpp
1>C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\xutility(1501,14):
error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
*,uint8_t *)': cannot convert argument 1 from 'unsigned char' to 'uint8_t *'
1>C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8068,16):
error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
*,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
1>C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8072,76):
error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
*,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
1>C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8083,24):
error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
*,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
1>C:\Program Files\Microsoft Visual
Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8097,24):
error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
*,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
1>Done building project "ConsoleTest2022.vcxproj" -- FAILED.
========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped ==========
========== Build completed at 13:49 and took 00,390 seconds ==========
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-25 14:06 +0300 |
| Message-ID | <20240925140649.00001a3a@yahoo.com> |
| In reply to | #120271 |
On Wed, 25 Sep 2024 13:52:51 +0300
Paavo Helde <eesnimi@osa.pri.ee> wrote:
> On 25.09.2024 13:31, Michael S wrote:
> > Below is an example of even more likely user mistake.
> > gcc generated 63 lines of errors, MSVC produced 69 lines and clang
> > had beaten both of them with 217 lines!
> > Even if, by chance, one or two of the messages make sense, they are
> > well hidden in piles of garbage.
> >
> > void my_sort3(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);
> > }
> >
>
> VStudio 2022 gives pretty clear error messages: cannot convert from
> an integer to a pointer, when calling operator():
>
> Build started at 13:49...
> 1>------ Build started: Project: ConsoleTest2022, Configuration:
> 1>Debug
> x64 ------
> 1>main.cpp
> 1>C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\xutility(1501,14):
> error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
> *,uint8_t *)': cannot convert argument 1 from 'unsigned char' to
> 'uint8_t *'
> 1>C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8068,16):
> error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
> *,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
> 1>C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8072,76):
> error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
> *,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
> 1>C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8083,24):
> error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
> *,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
> 1>C:\Program Files\Microsoft Visual
> Studio\2022\Professional\VC\Tools\MSVC\14.40.33807\include\algorithm(8097,24):
> error C2664: 'bool my_sort3::<unnamed-type-cmp>::operator ()(uint8_t
> *,uint8_t *)': cannot convert argument 1 from 'uint8_t' to 'uint8_t *'
> 1>Done building project "ConsoleTest2022.vcxproj" -- FAILED.
> ========== Build: 0 succeeded, 1 failed, 0 up-to-date, 0 skipped
> ========== ========== Build completed at 13:49 and took 00,390
> seconds ==========
>
I was testing with MSVC compiler/headers from VS2019
It produces this message as well, but only on 28th line. In my
experience it means that typical reader will give up earlier.
In your part of the world it could be different :-)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-09-25 14:22 +0200 |
| Message-ID | <vd0vab$3m0aj$3@dont-email.me> |
| In reply to | #120272 |
On 25/09/2024 13:06, Michael S wrote: > I was testing with MSVC compiler/headers from VS2019 > It produces this message as well, but only on 28th line. In my > experience it means that typical reader will give up earlier. > In your part of the world it could be different :-) > This might depend on your build environment. Sometimes what you see most easily is the last page of error messages, rather than the first page. (Of course it is easiest if there is no more than a single page or screenful of messages!)
[toc] | [prev] | [next] | [standalone]
| From | Muttley@dastardlyhq.com |
|---|---|
| Date | 2024-09-25 11:12 +0000 |
| Message-ID | <vd0r7d$3ln45$1@dont-email.me> |
| In reply to | #120269 |
On Wed, 25 Sep 2024 13:11:44 +0300
Michael S <already5chosen@yahoo.com> boringly babbled:
>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.
My version of Clang produced 305 lines of output. Yet right at the top:
t.cc:13:3: warning: template argument uses local type '(unnamed struct at t.cc:6
:3)' [-Wlocal-type-template-args]
std::sort(buf, buf+buflen, &cmp);
Which is all it needed to print. The other 304 lines of garbage could have
been reserved for the -Wall option.
For some reason Bonita finds this concept (pun intended) had to understand.
[toc] | [prev] | [next] | [standalone]
| From | Michael S <already5chosen@yahoo.com> |
|---|---|
| Date | 2024-09-25 14:30 +0300 |
| Message-ID | <20240925143021.00005cf4@yahoo.com> |
| In reply to | #120273 |
On Wed, 25 Sep 2024 11:12:45 -0000 (UTC)
Muttley@dastardlyhq.com wrote:
> On Wed, 25 Sep 2024 13:11:44 +0300
> Michael S <already5chosen@yahoo.com> boringly babbled:
> >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.
>
> My version of Clang produced 305 lines of output. Yet right at the
> top:
>
> t.cc:13:3: warning: template argument uses local type '(unnamed
> struct at t.cc:6 :3)' [-Wlocal-type-template-args]
> std::sort(buf, buf+buflen, &cmp);
>
> Which is all it needed to print. The other 304 lines of garbage could
> have been reserved for the -Wall option.
>
First, it's warning, not error.
Second, I don't know about you, but I personally have no idea what
is 'local type' and why it possibly could be a problem.
Even if the warning is somehow related to actual bug, which I doubt, the
relationship is far from obvious.
> For some reason Bonita finds this concept (pun intended) had to
> understand.
>
[toc] | [prev] | [next] | [standalone]
Page 3 of 13 — ← Prev page 1 2 [3] 4 5 … 13 Next page →
Back to top | Article view | comp.lang.c++
csiph-web