Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > comp.lang.c > #388775 > unrolled thread
| Started by | fir <fir@grunge.pl> |
|---|---|
| First post | 2024-10-31 13:11 +0100 |
| Last post | 2024-11-05 05:50 -0800 |
| Articles | 20 on this page of 263 — 18 participants |
Back to article view | Back to comp.lang.c
else ladders practice fir <fir@grunge.pl> - 2024-10-31 13:11 +0100
Re: else ladders practice Anton Shepelev <anton.txt@g{oogle}mail.com> - 2024-10-31 16:15 +0300
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 15:23 +0100
Re: else ladders practice James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-10-31 14:16 -0400
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-01 09:56 +0100
Re: else ladders practice James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-01 22:25 -0400
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-02 11:44 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-02 09:37 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-02 11:51 +0100
Re: else ladders practice James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-02 09:11 -0400
Re: else ladders practice Richard Harnden <richard.nospam@gmail.invalid> - 2024-10-31 13:25 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 14:48 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 15:17 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 15:43 +0100
Re: else ladders practice Bonita Montero <Bonita.Montero@gmail.com> - 2024-10-31 15:25 +0100
Re: else ladders practice Dan Purgert <dan@djph.net> - 2024-10-31 14:14 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 15:29 +0100
Re: else ladders practice Dan Purgert <dan@djph.net> - 2024-10-31 14:34 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-10-31 15:49 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-16 14:51 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-16 17:38 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-19 07:25 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-19 09:30 +0100
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-19 13:21 +0200
Re: else ladders practice James Kuyper <jameskuyper@alumni.caltech.edu> - 2024-11-16 10:14 -0500
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-19 14:41 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-30 14:07 -0800
Re: else ladders practice Lew Pitcher <lew.pitcher@digitalfreehold.ca> - 2024-11-16 15:37 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-17 05:51 -0800
Re: else ladders practice Dan Purgert <dan@djph.net> - 2024-11-20 12:31 +0000
Re: else ladders practice Rosario19 <Ros@invalid.invalid> - 2024-11-30 17:35 +0100
Re: else ladders practice Dan Purgert <dan@djph.net> - 2024-12-05 10:51 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-12-01 12:41 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-01 16:34 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-12-01 22:23 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-02 08:29 +0100
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-12-01 16:14 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-10-31 20:24 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-10-31 21:33 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-01 12:32 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-01 12:03 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-01 13:55 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-01 13:39 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-01 15:08 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-01 15:17 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-01 15:59 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-01 18:35 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-01 18:05 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-01 19:47 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-01 19:47 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-02 12:41 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-02 20:44 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-02 15:08 -0700
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 01:26 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-03 12:03 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 14:39 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 15:17 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 02:21 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-03 11:47 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 14:46 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 14:55 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-03 18:00 +0100
Re: else ladders practice Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-03 19:41 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-03 20:00 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-04 17:35 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-04 19:50 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-04 22:48 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-05 02:11 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-04 23:25 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-04 23:44 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-05 09:26 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-06 14:40 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-06 16:47 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-06 19:38 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-07 17:23 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-07 17:51 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-09 07:54 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-09 12:06 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-10 05:22 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-10 16:13 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-19 06:37 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-19 09:19 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-19 14:29 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-19 18:31 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-20 17:00 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-09 07:00 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-08 18:37 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-08 19:18 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-09 05:51 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-09 17:27 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-10 06:05 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-08 22:24 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-09 04:57 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-09 12:21 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-10 08:16 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-08 18:03 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-05 12:42 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-05 14:23 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-05 14:29 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-05 19:39 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-05 21:33 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-05 23:01 +0000
Re: else ladders practice Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-06 07:26 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-06 10:01 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-08 18:53 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-09 11:08 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-10 05:01 +0100
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-06 08:38 +0100
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-08 18:52 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-10 06:57 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-10 16:38 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-11 19:09 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-12 10:43 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-15 18:50 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-16 17:29 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-20 18:31 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-05 22:48 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-06 15:50 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-07 12:23 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-07 15:08 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-08 09:45 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-08 17:37 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-05 15:03 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-05 17:02 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-05 19:53 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-05 23:15 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-10 06:00 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-11 21:24 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-19 01:53 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-19 15:51 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-19 16:11 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-19 16:43 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-19 19:11 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-19 23:41 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-20 01:33 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-20 13:42 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-20 14:21 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-22 12:33 +0000
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-22 16:19 +0200
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-22 16:21 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-22 15:00 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-22 19:29 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-22 23:30 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-23 16:45 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-23 22:36 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 12:18 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-23 14:17 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 00:24 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-24 01:36 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-24 01:45 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 11:47 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 05:03 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-24 12:20 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 15:00 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-24 17:50 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 19:35 +0000
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-24 12:01 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-24 20:52 +0000
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-24 13:45 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 00:00 +0000
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-24 19:17 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 11:35 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-25 11:21 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 12:17 +0000
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 08:27 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 17:25 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-25 10:50 -0800
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 12:32 -0800
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 15:23 -0800
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-25 17:30 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-25 18:50 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 19:46 +0000
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 12:51 -0800
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-27 10:47 +0000
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-25 11:30 +0200
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-25 13:45 +0100
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-25 17:55 +0200
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-25 18:54 +0100
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 22:21 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 00:19 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 21:45 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-25 13:06 +0100
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-11-25 08:32 -0800
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-20 13:44 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-20 14:49 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-20 17:15 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-20 20:17 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-21 14:00 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-21 15:20 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 15:50 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-21 16:05 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 16:10 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-21 17:22 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-21 17:55 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-22 12:51 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-22 14:11 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-24 11:46 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-22 11:05 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-22 17:06 +0100
Re: else ladders practice Kaz Kylheku <643-408-1753@kylheku.com> - 2024-11-22 18:10 +0000
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-23 14:28 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-25 10:49 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 20:19 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-25 21:29 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-25 23:20 +0000
Re: else ladders practice scott@slp53.sl.home (Scott Lurndal) - 2024-11-26 01:09 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-26 01:28 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-26 04:29 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-26 13:31 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-27 21:18 -0800
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-28 14:37 +0200
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-28 15:25 +0000
Re: else ladders practice Michael S <already5chosen@yahoo.com> - 2024-11-28 17:46 +0200
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-12-01 13:04 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-12-01 15:13 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-12-06 23:30 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-12-07 12:40 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 21:25 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-30 11:26 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-12-01 13:19 +0000
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-02 06:09 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-12-02 14:44 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-02 19:19 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-12-02 18:48 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 14:41 +0100
Re: else ladders practice Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2024-12-05 15:51 -0800
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-07 11:58 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-05 16:24 -0800
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-28 14:27 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-28 18:28 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-28 18:25 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-29 10:36 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 15:29 -0800
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-30 03:46 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 20:40 -0800
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-30 11:00 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-12-04 17:34 -0800
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-12-05 14:21 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-29 21:03 -0800
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-19 22:40 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-20 00:16 +0000
Re: else ladders practice antispam@fricas.org (Waldek Hebisch) - 2024-11-20 14:38 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-20 23:29 +0000
Re: else ladders practice Mark Bourne <nntp.mbourne@spamgourmet.com> - 2024-11-19 20:51 +0000
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-22 01:09 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-01 14:05 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-02 11:09 -0700
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-02 14:25 -0700
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-03 01:53 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-03 20:00 -0800
Re: else ladders practice David Brown <david.brown@hesbynett.no> - 2024-11-04 08:18 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-04 11:56 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-04 13:29 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-04 12:38 +0000
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-04 13:46 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-04 16:02 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-04 16:06 +0100
Re: else ladders practice Bart <bc@freeuk.com> - 2024-11-04 15:21 +0000
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-04 16:52 +0100
Re: else ladders practice fir <fir@grunge.pl> - 2024-11-04 16:34 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-05 06:11 -0800
Re: else ladders practice Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2024-11-04 13:40 +0100
Re: else ladders practice Tim Rentsch <tr.17687@z991.linuxsc.com> - 2024-11-05 05:50 -0800
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-01 12:03 +0000 |
| Message-ID | <vg2g37$37mh3$1@dont-email.me> |
| In reply to | #388791 |
On 01/11/2024 11:32, fir wrote:
> Bart wrote:
>> ral clear patterns here: you're testing the same variable 'n' against
>> several mutually exclusive alternatives, which also happen to be
>> consecutive values.
>>
>> C is short of ways to express this, if you want to keep those
>> 'somethings' as inline code (otherwise arrays of function pointers or
>> even label pointers could be use
>
> so in short this groupo seem to have no conclusion but is tolerant foir
> various approaches as it seems
>
> imo the else latder is like most proper but i dont lkie it optically,
> swich case i also dont like (use as far i i remember never in my code,
> for years dont use even one)
>
> so i persnally would use bare ifs and maybe elses ocasionally
> (and switch should be mended but its fully not clear how,
>
> as to those pointer tables im not sure but im like measurad it onece and
> it was (not sure as to thsi as i dont remember exactly) slow maybe
> dependant on architecture so its noth wort of use (if i remember correctly)
Well, personally I don't like that repetition, that's why I mentioned
the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
writing out the numbers 1, 2, 3, 4, 5.
I also don't like the lack of exclusivity.
However I don't need to use C. If those 'somethings' were simple, or
were expressions, I could use syntax like this:
(n | s1, s2, s3, s4, s5)
If they were more elaborate statements, I would use a heavier syntax,
but still one where 'n' is only written once, and I don't need to repeat
'=='.
In the C version, you could mistakenly write 'm' instead of 'n', or '='
instead of '=='; it's more error prone, and a compiler might not be able
to detect it.
In the C, you could probably do something like this:
#define or else if
if (x == a) {}
or (x == b) {}
or (x == c) {}
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-01 13:55 +0100 |
| Message-ID | <6724CFD2.4030607@grunge.pl> |
| In reply to | #388792 |
Bart wrote:
> On 01/11/2024 11:32, fir wrote:
>> Bart wrote:
>>> ral clear patterns here: you're testing the same variable 'n' against
>>> several mutually exclusive alternatives, which also happen to be
>>> consecutive values.
>>>
>>> C is short of ways to express this, if you want to keep those
>>> 'somethings' as inline code (otherwise arrays of function pointers or
>>> even label pointers could be use
>>
>> so in short this groupo seem to have no conclusion but is tolerant
>> foir various approaches as it seems
>>
>> imo the else latder is like most proper but i dont lkie it optically,
>> swich case i also dont like (use as far i i remember never in my code,
>> for years dont use even one)
>>
>> so i persnally would use bare ifs and maybe elses ocasionally
>> (and switch should be mended but its fully not clear how,
>>
>> as to those pointer tables im not sure but im like measurad it onece
>> and it was (not sure as to thsi as i dont remember exactly) slow maybe
>> dependant on architecture so its noth wort of use (if i remember
>> correctly)
>
> Well, personally I don't like that repetition, that's why I mentioned
> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
> writing out the numbers 1, 2, 3, 4, 5.
>
> I also don't like the lack of exclusivity.
>
> However I don't need to use C. If those 'somethings' were simple, or
> were expressions, I could use syntax like this:
>
> (n | s1, s2, s3, s4, s5)
>
on a C ground more suitable is
{s1,s2,s3,s4,s5)[n]
//which is just array indexing, and could use also like
{
{0,0,0,0,0}
{0,1,1,1,0}
{1,1,1,1,1}
{0,1,1,1,0}
{0,0,1,0,0}} [j][i]
anmd so on
(already wrote on thsi once)
bot for general switch something more is needed probably
i could cnsider something like
n -1-> /*something / -2-> /*something / -3-> /*something /
but i dont know (this above line seem not quite good
> If they were more elaborate statements, I would use a heavier syntax,
> but still one where 'n' is only written once, and I don't need to repeat
> '=='.
>
> In the C version, you could mistakenly write 'm' instead of 'n', or '='
> instead of '=='; it's more error prone, and a compiler might not be able
> to detect it.
>
> In the C, you could probably do something like this:
>
> #define or else if
>
> if (x == a) {}
> or (x == b) {}
> or (x == c) {}
>
>
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-01 13:39 +0000 |
| Message-ID | <vg2llt$38ons$1@dont-email.me> |
| In reply to | #388793 |
On 01/11/2024 12:55, fir wrote:
> Bart wrote:
>> On 01/11/2024 11:32, fir wrote:
>>> Bart wrote:
>>>> ral clear patterns here: you're testing the same variable 'n' against
>>>> several mutually exclusive alternatives, which also happen to be
>>>> consecutive values.
>>>>
>>>> C is short of ways to express this, if you want to keep those
>>>> 'somethings' as inline code (otherwise arrays of function pointers or
>>>> even label pointers could be use
>>>
>>> so in short this groupo seem to have no conclusion but is tolerant
>>> foir various approaches as it seems
>>>
>>> imo the else latder is like most proper but i dont lkie it optically,
>>> swich case i also dont like (use as far i i remember never in my code,
>>> for years dont use even one)
>>>
>>> so i persnally would use bare ifs and maybe elses ocasionally
>>> (and switch should be mended but its fully not clear how,
>>>
>>> as to those pointer tables im not sure but im like measurad it onece
>>> and it was (not sure as to thsi as i dont remember exactly) slow maybe
>>> dependant on architecture so its noth wort of use (if i remember
>>> correctly)
>>
>> Well, personally I don't like that repetition, that's why I mentioned
>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>> writing out the numbers 1, 2, 3, 4, 5.
>>
>> I also don't like the lack of exclusivity.
>>
>> However I don't need to use C. If those 'somethings' were simple, or
>> were expressions, I could use syntax like this:
>>
>> (n | s1, s2, s3, s4, s5)
>>
>
> on a C ground more suitable is
>
> {s1,s2,s3,s4,s5)[n]
>
> //which is just array indexing
No, it's specifically not array indexing, as only one of s1 - s5 is
evaluated, or nothing is when n is not in range, eg. n is 100.
You could try something like that in C:
int x;
x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
(puts("d"),40)})[3];
printf("X=%d\n", x);
The output is:
a
b
c
d
X=40
Showing that all elements are evaluated first. If index is 100, the
result is also undefined.
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-01 15:08 +0100 |
| Message-ID | <2491a699388b5891a49ef960e1ad8bb689fdc2ed@i2pn2.org> |
| In reply to | #388795 |
Bart wrote:
> On 01/11/2024 12:55, fir wrote:
>> Bart wrote:
>>> On 01/11/2024 11:32, fir wrote:
>>>> Bart wrote:
>>>>> ral clear patterns here: you're testing the same variable 'n' against
>>>>> several mutually exclusive alternatives, which also happen to be
>>>>> consecutive values.
>>>>>
>>>>> C is short of ways to express this, if you want to keep those
>>>>> 'somethings' as inline code (otherwise arrays of function pointers or
>>>>> even label pointers could be use
>>>>
>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>> foir various approaches as it seems
>>>>
>>>> imo the else latder is like most proper but i dont lkie it optically,
>>>> swich case i also dont like (use as far i i remember never in my code,
>>>> for years dont use even one)
>>>>
>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>> (and switch should be mended but its fully not clear how,
>>>>
>>>> as to those pointer tables im not sure but im like measurad it onece
>>>> and it was (not sure as to thsi as i dont remember exactly) slow maybe
>>>> dependant on architecture so its noth wort of use (if i remember
>>>> correctly)
>>>
>>> Well, personally I don't like that repetition, that's why I mentioned
>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>> writing out the numbers 1, 2, 3, 4, 5.
>>>
>>> I also don't like the lack of exclusivity.
>>>
>>> However I don't need to use C. If those 'somethings' were simple, or
>>> were expressions, I could use syntax like this:
>>>
>>> (n | s1, s2, s3, s4, s5)
>>>
>>
>> on a C ground more suitable is
>>
>> {s1,s2,s3,s4,s5)[n]
>>
>> //which is just array indexing
>
> No, it's specifically not array indexing, as only one of s1 - s5 is
> evaluated, or nothing is when n is not in range, eg. n is 100.
>
> You could try something like that in C:
>
> int x;
>
> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
> (puts("d"),40)})[3];
>
> printf("X=%d\n", x);
>
> The output is:
>
> a
> b
> c
> d
> X=40
>
> Showing that all elements are evaluated first. If index is 100, the
> result is also undefined.
>
>
:-O
what is this, first time i see such thing
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-01 15:17 +0100 |
| Message-ID | <b681ee05856e165c26a5c29bf42a8d9d53843d6d@i2pn2.org> |
| In reply to | #388796 |
fir wrote:
> Bart wrote:
>> On 01/11/2024 12:55, fir wrote:
>>> Bart wrote:
>>>> On 01/11/2024 11:32, fir wrote:
>>>>> Bart wrote:
>>>>>> ral clear patterns here: you're testing the same variable 'n' against
>>>>>> several mutually exclusive alternatives, which also happen to be
>>>>>> consecutive values.
>>>>>>
>>>>>> C is short of ways to express this, if you want to keep those
>>>>>> 'somethings' as inline code (otherwise arrays of function pointers or
>>>>>> even label pointers could be use
>>>>>
>>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>>> foir various approaches as it seems
>>>>>
>>>>> imo the else latder is like most proper but i dont lkie it optically,
>>>>> swich case i also dont like (use as far i i remember never in my code,
>>>>> for years dont use even one)
>>>>>
>>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>>> (and switch should be mended but its fully not clear how,
>>>>>
>>>>> as to those pointer tables im not sure but im like measurad it onece
>>>>> and it was (not sure as to thsi as i dont remember exactly) slow maybe
>>>>> dependant on architecture so its noth wort of use (if i remember
>>>>> correctly)
>>>>
>>>> Well, personally I don't like that repetition, that's why I mentioned
>>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>>> writing out the numbers 1, 2, 3, 4, 5.
>>>>
>>>> I also don't like the lack of exclusivity.
>>>>
>>>> However I don't need to use C. If those 'somethings' were simple, or
>>>> were expressions, I could use syntax like this:
>>>>
>>>> (n | s1, s2, s3, s4, s5)
>>>>
>>>
>>> on a C ground more suitable is
>>>
>>> {s1,s2,s3,s4,s5)[n]
>>>
>>> //which is just array indexing
>>
>> No, it's specifically not array indexing, as only one of s1 - s5 is
>> evaluated, or nothing is when n is not in range, eg. n is 100.
>>
>> You could try something like that in C:
>>
>> int x;
>>
>> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
>> (puts("d"),40)})[3];
>>
>> printf("X=%d\n", x);
>>
>> The output is:
>>
>> a
>> b
>> c
>> d
>> X=40
>>
>> Showing that all elements are evaluated first. If index is 100, the
>> result is also undefined.
>>
>>
> :-O
> what is this, first time i see such thing
>
im surprised that it work, but in fact i meant that this syntax is old c
compatible but sych thing like
{printf("ONE"), printf("TWO"), printf("THREE")} [2]
shouldn evaluate al just the one is selected
like in array tab[23] not eveluates something other than tab[23]
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-01 15:59 +0000 |
| Message-ID | <vg2ttn$3a4lk$1@dont-email.me> |
| In reply to | #388797 |
On 01/11/2024 14:17, fir wrote:
> fir wrote:
>> Bart wrote:
>>> On 01/11/2024 12:55, fir wrote:
>>>> Bart wrote:
>>>>> On 01/11/2024 11:32, fir wrote:
>>>>>> Bart wrote:
>>>>>>> ral clear patterns here: you're testing the same variable 'n'
>>>>>>> against
>>>>>>> several mutually exclusive alternatives, which also happen to be
>>>>>>> consecutive values.
>>>>>>>
>>>>>>> C is short of ways to express this, if you want to keep those
>>>>>>> 'somethings' as inline code (otherwise arrays of function
>>>>>>> pointers or
>>>>>>> even label pointers could be use
>>>>>>
>>>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>>>> foir various approaches as it seems
>>>>>>
>>>>>> imo the else latder is like most proper but i dont lkie it optically,
>>>>>> swich case i also dont like (use as far i i remember never in my
>>>>>> code,
>>>>>> for years dont use even one)
>>>>>>
>>>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>>>> (and switch should be mended but its fully not clear how,
>>>>>>
>>>>>> as to those pointer tables im not sure but im like measurad it onece
>>>>>> and it was (not sure as to thsi as i dont remember exactly) slow
>>>>>> maybe
>>>>>> dependant on architecture so its noth wort of use (if i remember
>>>>>> correctly)
>>>>>
>>>>> Well, personally I don't like that repetition, that's why I mentioned
>>>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>>>> writing out the numbers 1, 2, 3, 4, 5.
>>>>>
>>>>> I also don't like the lack of exclusivity.
>>>>>
>>>>> However I don't need to use C. If those 'somethings' were simple, or
>>>>> were expressions, I could use syntax like this:
>>>>>
>>>>> (n | s1, s2, s3, s4, s5)
>>>>>
>>>>
>>>> on a C ground more suitable is
>>>>
>>>> {s1,s2,s3,s4,s5)[n]
>>>>
>>>> //which is just array indexing
>>>
>>> No, it's specifically not array indexing, as only one of s1 - s5 is
>>> evaluated, or nothing is when n is not in range, eg. n is 100.
>>>
>>> You could try something like that in C:
>>>
>>> int x;
>>>
>>> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
>>> (puts("d"),40)})[3];
>>>
>>> printf("X=%d\n", x);
>>>
>>> The output is:
>>>
>>> a
>>> b
>>> c
>>> d
>>> X=40
>>>
>>> Showing that all elements are evaluated first. If index is 100, the
>>> result is also undefined.
>>>
>>>
>> :-O
>> what is this, first time i see such thing
>>
> im surprised that it work, but in fact i meant that this syntax is old c
> compatible but sych thing like
>
>
> {printf("ONE"), printf("TWO"), printf("THREE")} [2]
>
> shouldn evaluate al just the one is selected
> like in array tab[23] not eveluates something other than tab[23]
It's a 'compound literal'. It allows you to have the same {...}
initialisation data format, but anywhere, not just for initialing.
However it always needs a cast:
(int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2];
This prints ONETWOTHREE, it also then indexes the 3rd value of the
array, which is 5, as returned by printf, so this:
printf("%d\n", (int[]){printf("ONE"), printf("TWO"),
printf("THREE")}[2]);
prints ONETWOTHREE5
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-01 18:35 +0100 |
| Message-ID | <vg33gs$3b8n5$1@dont-email.me> |
| In reply to | #388798 |
On 01/11/2024 16:59, Bart wrote:
> On 01/11/2024 14:17, fir wrote:
>> fir wrote:
>>> Bart wrote:
>>>> On 01/11/2024 12:55, fir wrote:
>>>>> Bart wrote:
>>>>>> On 01/11/2024 11:32, fir wrote:
>>>>>>> Bart wrote:
>>>>>>>> ral clear patterns here: you're testing the same variable 'n'
>>>>>>>> against
>>>>>>>> several mutually exclusive alternatives, which also happen to be
>>>>>>>> consecutive values.
>>>>>>>>
>>>>>>>> C is short of ways to express this, if you want to keep those
>>>>>>>> 'somethings' as inline code (otherwise arrays of function
>>>>>>>> pointers or
>>>>>>>> even label pointers could be use
>>>>>>>
>>>>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>>>>> foir various approaches as it seems
>>>>>>>
>>>>>>> imo the else latder is like most proper but i dont lkie it
>>>>>>> optically,
>>>>>>> swich case i also dont like (use as far i i remember never in my
>>>>>>> code,
>>>>>>> for years dont use even one)
>>>>>>>
>>>>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>>>>> (and switch should be mended but its fully not clear how,
>>>>>>>
>>>>>>> as to those pointer tables im not sure but im like measurad it onece
>>>>>>> and it was (not sure as to thsi as i dont remember exactly) slow
>>>>>>> maybe
>>>>>>> dependant on architecture so its noth wort of use (if i remember
>>>>>>> correctly)
>>>>>>
>>>>>> Well, personally I don't like that repetition, that's why I mentioned
>>>>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>>>>> writing out the numbers 1, 2, 3, 4, 5.
>>>>>>
>>>>>> I also don't like the lack of exclusivity.
>>>>>>
>>>>>> However I don't need to use C. If those 'somethings' were simple, or
>>>>>> were expressions, I could use syntax like this:
>>>>>>
>>>>>> (n | s1, s2, s3, s4, s5)
>>>>>>
>>>>>
>>>>> on a C ground more suitable is
>>>>>
>>>>> {s1,s2,s3,s4,s5)[n]
>>>>>
>>>>> //which is just array indexing
>>>>
>>>> No, it's specifically not array indexing, as only one of s1 - s5 is
>>>> evaluated, or nothing is when n is not in range, eg. n is 100.
>>>>
>>>> You could try something like that in C:
>>>>
>>>> int x;
>>>>
>>>> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
>>>> (puts("d"),40)})[3];
>>>>
>>>> printf("X=%d\n", x);
>>>>
>>>> The output is:
>>>>
>>>> a
>>>> b
>>>> c
>>>> d
>>>> X=40
>>>>
>>>> Showing that all elements are evaluated first. If index is 100, the
>>>> result is also undefined.
>>>>
>>>>
>>> :-O
>>> what is this, first time i see such thing
>>>
>> im surprised that it work, but in fact i meant that this syntax is old
>> c compatible but sych thing like
>>
>>
>> {printf("ONE"), printf("TWO"), printf("THREE")} [2]
>>
>> shouldn evaluate al just the one is selected
>> like in array tab[23] not eveluates something other than tab[23]
>
> It's a 'compound literal'. It allows you to have the same {...}
> initialisation data format, but anywhere, not just for initialing.
> However it always needs a cast:
>
> (int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2];
>
> This prints ONETWOTHREE, it also then indexes the 3rd value of the
> array, which is 5, as returned by printf, so this:
>
> printf("%d\n", (int[]){printf("ONE"), printf("TWO"),
> printf("THREE")}[2]);
>
> prints ONETWOTHREE5
>
>
What you have written here is all correct, but a more common method
would be to avoid having three printf's :
void shout_a_number(int n) {
printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
}
That's more likely to match what people would want.
Of course, you may need to sanity-check the value of "n" here!
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-01 18:05 +0000 |
| Message-ID | <vg358c$3bk7t$1@dont-email.me> |
| In reply to | #388799 |
On 01/11/2024 17:35, David Brown wrote:
> On 01/11/2024 16:59, Bart wrote:
>> On 01/11/2024 14:17, fir wrote:
>>> fir wrote:
>>>> Bart wrote:
>>>>> On 01/11/2024 12:55, fir wrote:
>>>>>> Bart wrote:
>>>>>>> On 01/11/2024 11:32, fir wrote:
>>>>>>>> Bart wrote:
>>>>>>>>> ral clear patterns here: you're testing the same variable 'n'
>>>>>>>>> against
>>>>>>>>> several mutually exclusive alternatives, which also happen to be
>>>>>>>>> consecutive values.
>>>>>>>>>
>>>>>>>>> C is short of ways to express this, if you want to keep those
>>>>>>>>> 'somethings' as inline code (otherwise arrays of function
>>>>>>>>> pointers or
>>>>>>>>> even label pointers could be use
>>>>>>>>
>>>>>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>>>>>> foir various approaches as it seems
>>>>>>>>
>>>>>>>> imo the else latder is like most proper but i dont lkie it
>>>>>>>> optically,
>>>>>>>> swich case i also dont like (use as far i i remember never in my
>>>>>>>> code,
>>>>>>>> for years dont use even one)
>>>>>>>>
>>>>>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>>>>>> (and switch should be mended but its fully not clear how,
>>>>>>>>
>>>>>>>> as to those pointer tables im not sure but im like measurad it
>>>>>>>> onece
>>>>>>>> and it was (not sure as to thsi as i dont remember exactly) slow
>>>>>>>> maybe
>>>>>>>> dependant on architecture so its noth wort of use (if i remember
>>>>>>>> correctly)
>>>>>>>
>>>>>>> Well, personally I don't like that repetition, that's why I
>>>>>>> mentioned
>>>>>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>>>>>> writing out the numbers 1, 2, 3, 4, 5.
>>>>>>>
>>>>>>> I also don't like the lack of exclusivity.
>>>>>>>
>>>>>>> However I don't need to use C. If those 'somethings' were simple, or
>>>>>>> were expressions, I could use syntax like this:
>>>>>>>
>>>>>>> (n | s1, s2, s3, s4, s5)
>>>>>>>
>>>>>>
>>>>>> on a C ground more suitable is
>>>>>>
>>>>>> {s1,s2,s3,s4,s5)[n]
>>>>>>
>>>>>> //which is just array indexing
>>>>>
>>>>> No, it's specifically not array indexing, as only one of s1 - s5 is
>>>>> evaluated, or nothing is when n is not in range, eg. n is 100.
>>>>>
>>>>> You could try something like that in C:
>>>>>
>>>>> int x;
>>>>>
>>>>> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
>>>>> (puts("d"),40)})[3];
>>>>>
>>>>> printf("X=%d\n", x);
>>>>>
>>>>> The output is:
>>>>>
>>>>> a
>>>>> b
>>>>> c
>>>>> d
>>>>> X=40
>>>>>
>>>>> Showing that all elements are evaluated first. If index is 100, the
>>>>> result is also undefined.
>>>>>
>>>>>
>>>> :-O
>>>> what is this, first time i see such thing
>>>>
>>> im surprised that it work, but in fact i meant that this syntax is
>>> old c compatible but sych thing like
>>>
>>>
>>> {printf("ONE"), printf("TWO"), printf("THREE")} [2]
>>>
>>> shouldn evaluate al just the one is selected
>>> like in array tab[23] not eveluates something other than tab[23]
>>
>> It's a 'compound literal'. It allows you to have the same {...}
>> initialisation data format, but anywhere, not just for initialing.
>> However it always needs a cast:
>>
>> (int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2];
>>
>> This prints ONETWOTHREE, it also then indexes the 3rd value of the
>> array, which is 5, as returned by printf, so this:
>>
>> printf("%d\n", (int[]){printf("ONE"), printf("TWO"),
>> printf("THREE")}[2]);
>>
>> prints ONETWOTHREE5
>>
>>
>
> What you have written here is all correct, but a more common method
> would be to avoid having three printf's :
>
> void shout_a_number(int n) {
> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
> }
>
> That's more likely to match what people would want.
I was also trying to show that all elements are evaluated, so each has
to have some side-effect to illustrate that.
A true N-way-select construct (C only really has ?:) would evaluate only
one, and would deal with an out-of-range condition.
(In my implementations, a default/else branch value must be provided if
the whole thing is expected to return a value.)
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-01 19:47 +0100 |
| Message-ID | <vg37nr$3bo0c$1@dont-email.me> |
| In reply to | #388800 |
On 01/11/2024 19:05, Bart wrote:
> On 01/11/2024 17:35, David Brown wrote:
>> On 01/11/2024 16:59, Bart wrote:
>>> On 01/11/2024 14:17, fir wrote:
>>>> fir wrote:
>>>>> Bart wrote:
>>>>>> On 01/11/2024 12:55, fir wrote:
>>>>>>> Bart wrote:
>>>>>>>> On 01/11/2024 11:32, fir wrote:
>>>>>>>>> Bart wrote:
>>>>>>>>>> ral clear patterns here: you're testing the same variable 'n'
>>>>>>>>>> against
>>>>>>>>>> several mutually exclusive alternatives, which also happen to be
>>>>>>>>>> consecutive values.
>>>>>>>>>>
>>>>>>>>>> C is short of ways to express this, if you want to keep those
>>>>>>>>>> 'somethings' as inline code (otherwise arrays of function
>>>>>>>>>> pointers or
>>>>>>>>>> even label pointers could be use
>>>>>>>>>
>>>>>>>>> so in short this groupo seem to have no conclusion but is tolerant
>>>>>>>>> foir various approaches as it seems
>>>>>>>>>
>>>>>>>>> imo the else latder is like most proper but i dont lkie it
>>>>>>>>> optically,
>>>>>>>>> swich case i also dont like (use as far i i remember never in
>>>>>>>>> my code,
>>>>>>>>> for years dont use even one)
>>>>>>>>>
>>>>>>>>> so i persnally would use bare ifs and maybe elses ocasionally
>>>>>>>>> (and switch should be mended but its fully not clear how,
>>>>>>>>>
>>>>>>>>> as to those pointer tables im not sure but im like measurad it
>>>>>>>>> onece
>>>>>>>>> and it was (not sure as to thsi as i dont remember exactly)
>>>>>>>>> slow maybe
>>>>>>>>> dependant on architecture so its noth wort of use (if i remember
>>>>>>>>> correctly)
>>>>>>>>
>>>>>>>> Well, personally I don't like that repetition, that's why I
>>>>>>>> mentioned
>>>>>>>> the patterns. You're writing 'n' 5 times, '==' 5 times, and you're
>>>>>>>> writing out the numbers 1, 2, 3, 4, 5.
>>>>>>>>
>>>>>>>> I also don't like the lack of exclusivity.
>>>>>>>>
>>>>>>>> However I don't need to use C. If those 'somethings' were
>>>>>>>> simple, or
>>>>>>>> were expressions, I could use syntax like this:
>>>>>>>>
>>>>>>>> (n | s1, s2, s3, s4, s5)
>>>>>>>>
>>>>>>>
>>>>>>> on a C ground more suitable is
>>>>>>>
>>>>>>> {s1,s2,s3,s4,s5)[n]
>>>>>>>
>>>>>>> //which is just array indexing
>>>>>>
>>>>>> No, it's specifically not array indexing, as only one of s1 - s5 is
>>>>>> evaluated, or nothing is when n is not in range, eg. n is 100.
>>>>>>
>>>>>> You could try something like that in C:
>>>>>>
>>>>>> int x;
>>>>>>
>>>>>> x = ((int[]){(puts("a"),10), (puts("b"),20), (puts("c"), 30),
>>>>>> (puts("d"),40)})[3];
>>>>>>
>>>>>> printf("X=%d\n", x);
>>>>>>
>>>>>> The output is:
>>>>>>
>>>>>> a
>>>>>> b
>>>>>> c
>>>>>> d
>>>>>> X=40
>>>>>>
>>>>>> Showing that all elements are evaluated first. If index is 100, the
>>>>>> result is also undefined.
>>>>>>
>>>>>>
>>>>> :-O
>>>>> what is this, first time i see such thing
>>>>>
>>>> im surprised that it work, but in fact i meant that this syntax is
>>>> old c compatible but sych thing like
>>>>
>>>>
>>>> {printf("ONE"), printf("TWO"), printf("THREE")} [2]
>>>>
>>>> shouldn evaluate al just the one is selected
>>>> like in array tab[23] not eveluates something other than tab[23]
>>>
>>> It's a 'compound literal'. It allows you to have the same {...}
>>> initialisation data format, but anywhere, not just for initialing.
>>> However it always needs a cast:
>>>
>>> (int[]){printf("ONE"), printf("TWO"), printf("THREE")}[2];
>>>
>>> This prints ONETWOTHREE, it also then indexes the 3rd value of the
>>> array, which is 5, as returned by printf, so this:
>>>
>>> printf("%d\n", (int[]){printf("ONE"), printf("TWO"),
>>> printf("THREE")}[2]);
>>>
>>> prints ONETWOTHREE5
>>>
>>>
>>
>> What you have written here is all correct, but a more common method
>> would be to avoid having three printf's :
>>
>> void shout_a_number(int n) {
>> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>> }
>>
>> That's more likely to match what people would want.
>
> I was also trying to show that all elements are evaluated, so each has
> to have some side-effect to illustrate that.
Fair enough.
>
> A true N-way-select construct (C only really has ?:) would evaluate only
> one, and would deal with an out-of-range condition.
That's a matter of opinion and design choice, rather than being
requirements for a "true" select construct. You are free to choose the
rules you want for your own language, but you are not free to dictate
what you think the rules should be for others. (You are welcome to
/opinions/, of course.)
>
> (In my implementations, a default/else branch value must be provided if
> the whole thing is expected to return a value.)
>
OK, if that's what you want. My preference, if I were putting together
what /I/ thought was an idea language for /my/ use, would be heavy use
of explicit specifications and contracts for code, so that a
default/else branch is either disallowed (if there the selection covers
all legal values) or required (if the selection is abbreviated). A
default value "just in case" is, IMHO, worse than useless.
Different people, different preferences.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-01 19:47 +0000 |
| Message-ID | <vg3b98$3cc8q$1@dont-email.me> |
| In reply to | #388801 |
On 01/11/2024 18:47, David Brown wrote:
> On 01/11/2024 19:05, Bart wrote:
>> On 01/11/2024 17:35, David Brown wrote:
>>>
>>> What you have written here is all correct, but a more common method
>>> would be to avoid having three printf's :
>>>
>>> void shout_a_number(int n) {
>>> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>>> }
>>>
>>> That's more likely to match what people would want.
>>
>> I was also trying to show that all elements are evaluated, so each has
>> to have some side-effect to illustrate that.
>
> Fair enough.
>
>>
>> A true N-way-select construct (C only really has ?:) would evaluate
>> only one, and would deal with an out-of-range condition.
>
> That's a matter of opinion and design choice, rather than being
> requirements for a "true" select construct.
I don't think it's just opinion.
In general, an if-else-if chain (which was the point of the OP), would
evaluate only one branch. So would a switch-case construct if sensibly
implemented (in C's version, anything goes).
The same applies to C's c?a:b operator: only one of a or b is evaluated,
not both.
(This also why implementing if, switch, ?: via functions, which lots are
keen to do in the reddit PL forum, requires closures, lazy evaluation or
other advanced features.)
> You are free to choose the
> rules you want for your own language, but you are not free to dictate
> what you think the rules should be for others. (You are welcome to
> /opinions/, of course.)
>
>>
>> (In my implementations, a default/else branch value must be provided
>> if the whole thing is expected to return a value.)
>>
>
> OK, if that's what you want. My preference, if I were putting together
> what /I/ thought was an idea language for /my/ use, would be heavy use
> of explicit specifications and contracts for code, so that a
> default/else branch is either disallowed (if there the selection covers
> all legal values) or required (if the selection is abbreviated). A
> default value "just in case" is, IMHO, worse than useless.
All such multiway constructs in my languages (there are 4, one of which
the job of both 'if' and C's ?:) have an optional else branch. A
missing 'else' has an notional 'void' type.
But it becomes mandatory if the whole thing returns a value, to satisfy
the type system, because otherwise it will try and match with 'void'.
SOMETHING needs to happen when none of the branches are executed; what
value would be returned then? The behaviour needs to be defined. You
don't want to rely on compiler analysis for this stuff.
In C on the other hand, the ':' of '?:' is always needed, even when it
is not expected to yield a value. Hence you often see this things like this:
p == NULL ? puts("error"): 0;
Here, gcc at least, also requires the types of the two branches to
match, even though the whole construct yields no common value. Meanwhile
I allow this (if I was keen on a compact form):
(p = nil | print "error")
No else is needed.
[toc] | [prev] | [next] | [standalone]
| From | David Brown <david.brown@hesbynett.no> |
|---|---|
| Date | 2024-11-02 12:41 +0100 |
| Message-ID | <vg5351$3pada$1@dont-email.me> |
| In reply to | #388802 |
On 01/11/2024 20:47, Bart wrote:
> On 01/11/2024 18:47, David Brown wrote:
>> On 01/11/2024 19:05, Bart wrote:
>>> On 01/11/2024 17:35, David Brown wrote:
>
>>>>
>>>> What you have written here is all correct, but a more common method
>>>> would be to avoid having three printf's :
>>>>
>>>> void shout_a_number(int n) {
>>>> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>>>> }
>>>>
>>>> That's more likely to match what people would want.
>>>
>>> I was also trying to show that all elements are evaluated, so each
>>> has to have some side-effect to illustrate that.
>>
>> Fair enough.
>>
>>>
>>> A true N-way-select construct (C only really has ?:) would evaluate
>>> only one, and would deal with an out-of-range condition.
>>
>> That's a matter of opinion and design choice, rather than being
>> requirements for a "true" select construct.
>
> I don't think it's just opinion.
Yes, it is.
I don't disagree that such an "select one of these and evaluate only
that" construct can be a useful thing, or a perfectly good alternative
to to an "evaluate all of these then select one of them" construct. But
you are completely wrong to think that one of these two is somehow the
"true" or only correct way to have a selection.
In some languages, the construct for "A or B" will evaluate both, then
"or" them. In other languages, it will evaluate "A" then only evaluate
"B" if necessary. In others, expressions "A" and "B" cannot have
side-effects, so the evaluation or not makes no difference. All of
these are perfectly valid design choices for a language.
>
> In general, an if-else-if chain (which was the point of the OP), would
> evaluate only one branch.
It evaluates all the conditionals down the chain until it hits a "true"
result, then evaluates the body of the "if" that matches, then skips the
rest.
(Of course generated code can evaluate all sorts of things in different
orders, as long as observable behaviour - side-effects - are correct.)
> So would a switch-case construct if sensibly
> implemented (in C's version, anything goes).
>
C's switch is perfectly simply and clearly defined. It is not "anything
goes". The argument to the switch is evaluated once, then control jumps
to the label of the switch case, then evaluation continues from that
point. It is totally straight-forward.
You might not like the "fall-through" concept or the way C's switch does
not quite fit with structured programming. If so, I'd agree entirely.
The requirement for lots of "break;" statements in most C switch uses is
a source of countless errors in C coding and IMHO a clear mistake in the
language design. But that does not hinder C's switch statements from
being very useful, very easy to understand (when used sensibly), and
with no doubts about how they work (again, when used sensibly).
> The same applies to C's c?a:b operator: only one of a or b is evaluated,
> not both.
You are conflating several ideas, then you wrote something that you
/know/ is pure FUD about C's switch statements. So writing "The same
applies" makes no sense.
You are, of course, correct that in "c ? a : b", "c" is evaluated first
and then one and only one of "a" and "b".
>
> (This also why implementing if, switch, ?: via functions, which lots are
> keen to do in the reddit PL forum, requires closures, lazy evaluation or
> other advanced features.)
>
Yes, you'd need something like that to implement such "short-circuit"
operators using functions in C. In other languages, things may be
different.
>
>> You are free to choose the rules you want for your own language, but
>> you are not free to dictate what you think the rules should be for
>> others. (You are welcome to /opinions/, of course.)
>>
>>>
>>> (In my implementations, a default/else branch value must be provided
>>> if the whole thing is expected to return a value.)
>>>
>>
>> OK, if that's what you want. My preference, if I were putting
>> together what /I/ thought was an idea language for /my/ use, would be
>> heavy use of explicit specifications and contracts for code, so that a
>> default/else branch is either disallowed (if there the selection
>> covers all legal values) or required (if the selection is
>> abbreviated). A default value "just in case" is, IMHO, worse than
>> useless.
>
> All such multiway constructs in my languages (there are 4, one of which
> the job of both 'if' and C's ?:) have an optional else branch. A
> missing 'else' has an notional 'void' type.
>
> But it becomes mandatory if the whole thing returns a value, to satisfy
> the type system, because otherwise it will try and match with 'void'.
>
Your language, your choice. I'd question the whole idea of having a
construct that can evaluate to something of different types in the first
place, whether or not it returns a value, but that's your choice.
> SOMETHING needs to happen when none of the branches are executed; what
> value would be returned then? The behaviour needs to be defined. You
> don't want to rely on compiler analysis for this stuff.
In my hypothetical language described above, it never happens that none
of the branches are executed.
Do you feel you need to write code like this?
const char * flag_to_text_A(bool b) {
if (b == true) {
return "It's true!";
} else if (b == false) {
return "It's false!";
} else {
return "Schrödinger's cat has escaped!";
}
}
When you have your "else" or "default" clause that is added for
something that can't ever happen, how do you test it?
>
> In C on the other hand, the ':' of '?:' is always needed, even when it
> is not expected to yield a value. Hence you often see this things like
> this:
>
> p == NULL ? puts("error"): 0;
Given that the tertiary operator chooses between two things, it seems
fairly obvious that you need two alternatives to choose from - having a
choice operator without at least two choices would be rather useless.
I can't say I have ever seen the tertiary operator used like this.
There are a few C programmers that like to code with everything as
expressions, using commas instead of semicolons, but they are IMHO
mostly just being smart-arses. It's a lot more common to write :
if (!p) puts("error");
And in most cases, you'd have a return when "p" is not valid, or make
the rest of the function part of the conditional rather than continuing
with a null "p".
>
> Here, gcc at least, also requires the types of the two branches to
> match, even though the whole construct yields no common value.
The C standards require a certain level of type matching here - it is
not gcc specific. (The exact requirements are in 6.5.15p3 of the C
standards - I am sure you read these when you implemented your own C
compiler.) And yes, the whole construct /does/ yield a value of a
common type. It is not the language's fault if some hypothetical
programmer writes something in an odd manner.
> Meanwhile
> I allow this (if I was keen on a compact form):
>
> (p = nil | print "error")
>
> No else is needed.
>
In C you could write :
p == NULL || puts("error");
which is exactly the same structure.
I think all of these, including your construct in your language, are
smart-arse choices compared to a simple "if" statement, but personal
styles and preferences vary.
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-02 20:44 +0000 |
| Message-ID | <vg62vg$3uv02$1@dont-email.me> |
| In reply to | #388807 |
On 02/11/2024 11:41, David Brown wrote:
> On 01/11/2024 20:47, Bart wrote:
>> On 01/11/2024 18:47, David Brown wrote:
>>> On 01/11/2024 19:05, Bart wrote:
>>>> On 01/11/2024 17:35, David Brown wrote:
>>
>>>>>
>>>>> What you have written here is all correct, but a more common method
>>>>> would be to avoid having three printf's :
>>>>>
>>>>> void shout_a_number(int n) {
>>>>> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>>>>> }
>>>>>
>>>>> That's more likely to match what people would want.
>>>>
>>>> I was also trying to show that all elements are evaluated, so each
>>>> has to have some side-effect to illustrate that.
>>>
>>> Fair enough.
>>>
>>>>
>>>> A true N-way-select construct (C only really has ?:) would evaluate
>>>> only one, and would deal with an out-of-range condition.
>>>
>>> That's a matter of opinion and design choice, rather than being
>>> requirements for a "true" select construct.
>>
>> I don't think it's just opinion.
>
> Yes, it is.
Then we disagree on what 'multi-way' select might mean. I think it means
branching, even if notionally, on one-of-N possible code paths.
The whole construct may or may not return a value. If it does, then one
of the N paths must be a default path.
> I don't disagree that such an "select one of these and evaluate only
> that" construct can be a useful thing, or a perfectly good alternative
> to to an "evaluate all of these then select one of them" construct. But
> you are completely wrong to think that one of these two is somehow the
> "true" or only correct way to have a selection.
>
> In some languages, the construct for "A or B" will evaluate both, then
> "or" them. In other languages, it will evaluate "A" then only evaluate
> "B" if necessary. In others, expressions "A" and "B" cannot have
> side-effects, so the evaluation or not makes no difference. All of
> these are perfectly valid design choices for a language.
Those logical operators that may or may not short-circuit.
One feature of my concept of 'multi-way select' is that there is one or
more controlling expressions which determine which path is followed.
So, I'd be interested in what you think of as a multi-way select which
may evaluate more than one branch. Or was it that 'or' example?
>>
>> In general, an if-else-if chain (which was the point of the OP), would
>> evaluate only one branch.
>
> It evaluates all the conditionals down the chain until it hits a "true"
> result, then evaluates the body of the "if" that matches, then skips the
> rest.
I don't count evaluating the conditionals: here it is the branches that
count (since it is one of those that is 'selected' via those
conditionals), and here you admit that only one is executed.
> (Of course generated code can evaluate all sorts of things in different
> orders, as long as observable behaviour - side-effects - are correct.)
>
>> So would a switch-case construct if sensibly implemented (in C's
>> version, anything goes).
>>
>
> C's switch is perfectly simply and clearly defined. It is not "anything
> goes". The argument to the switch is evaluated once, then control jumps
> to the label of the switch case, then evaluation continues from that
> point. It is totally straight-forward.
It's pretty much the complete opposite of straightforward, as you go on
to demonstrate.
C 'switch' looks like it might be properly structured if written
sensibly. The reality is different: what follows `switch (x)` is just
ONE C statement, often a compound statement.
Case labels can located ANYWHERE within that statement, including within
nested statements (eg. inside a for-statement), and including
'default:', which could go before all the case labels!
The only place they can't go is within a further nested switch, which
has its own set of case-labels.
Control tranfers to any matching case-label or 'default:' and just keeps
executing code within that ONE statement, unless it hits 'break;'.
It is totally chaotic. This is what I mean by 'anything goes'. This is a
valid switch statement for example: 'switch (x);'.
You can't use such a statement as a solid basis for a multi-way
construct that returns a value, since it is, in general, impossible to
sensibly enumerate the N branches.
> You might not like the "fall-through" concept or the way C's switch does
> not quite fit with structured programming. If so, I'd agree entirely.
Good.
> The requirement for lots of "break;" statements in most C switch uses is
> a source of countless errors in C coding and IMHO a clear mistake in the
> language design. But that does not hinder C's switch statements from
> being very useful, very easy to understand (when used sensibly), and
> with no doubts about how they work (again, when used sensibly).
>
>> The same applies to C's c?a:b operator: only one of a or b is
>> evaluated, not both.
>
> You are conflating several ideas, then you wrote something that you
> /know/ is pure FUD about C's switch statements.
It wasn't. YOU wrote FUD when you called them straightforward. I would
bet you that the majority of C programmers don't know just how weird
switch is.
> So writing "The same
> applies" makes no sense.
'The same applies' was in reference to this previous remark of mine:
"In general, an if-else-if chain (which was the point of the OP), would
evaluate only one branch. So would a switch-case construct if sensibly
implemented (in C's version, anything goes). "
> You are, of course, correct that in "c ? a : b", "c" is evaluated first
> and then one and only one of "a" and "b".
And here you confirm that it does in fact apply: only one branch is
executed.
You can't apply it to C's switch as there is no rigorous way of even
determining what is a branch. Maybe it is a span between 2 case labels?
But then, one of those might be in a different nested statement!
>>
>> (This also why implementing if, switch, ?: via functions, which lots
>> are keen to do in the reddit PL forum, requires closures, lazy
>> evaluation or other advanced features.)
>>
>
> Yes, you'd need something like that to implement such "short-circuit"
> operators using functions in C. In other languages, things may be
> different.
Yes, short-circut operators would need the same features. That's why
it's easier to build this stuff into a core language than to try and
design a language where 90% of the features are there to implement what
should be core features.
>> But it becomes mandatory if the whole thing returns a value, to
>> satisfy the type system, because otherwise it will try and match with
>> 'void'.
>>
>
> Your language, your choice.
These things tend to come about because that is the natural order that
comes through. It's something I observed rather than decided.
> I'd question the whole idea of having a
> construct that can evaluate to something of different types in the first
> place, whether or not it returns a value, but that's your choice.
If the result of a multi-way execution doesn't yield a value to be used,
then the types don't matter.
If it does, then they DO matter, as they have to be compatible types in
a static language.
This is just common sense; I don't know why you're questioning it. (I'd
quite like to see a language of your design!)
>> SOMETHING needs to happen when none of the branches are executed; what
>> value would be returned then? The behaviour needs to be defined. You
>> don't want to rely on compiler analysis for this stuff.
>
> In my hypothetical language described above, it never happens that none
> of the branches are executed.
>
> Do you feel you need to write code like this?
>
> const char * flag_to_text_A(bool b) {
> if (b == true) {
> return "It's true!";
> } else if (b == false) {
> return "It's false!";
> } else {
> return "Schrödinger's cat has escaped!";
> }
> }
>
> When you have your "else" or "default" clause that is added for
> something that can't ever happen, how do you test it?
I write code like this:
func F(b) =
if X then
A # 'return' is optional
elsif Y then
B
fi
end
As it is, it requires 'else' (because this is a value-returning function.
X Y A B are arbitrary expressions. The need for 'else' is determined
during type analysis. Whether it will ever execute the default path
would be up to extra analysis, that I don't do, and would anyway be done
later.
You can't design a language like this where valid syntax depends on
compiler and what it might or might not discover when analysing the code.
The rule instead is simple: where a multi-path construct yields a value,
then it needs the default branch, always.
A compiler /might/ figure out it isn't needed, and not generate that bit
of code. (Or as I suggested, it might insert a suitable branch.)
You seem to like putting the onus on compiler writers to have to analyse
programs to the limit.
(Note that my example is for dynamic code; there X Y may only be known
at runtime anyway.)
In my languages, the last statement of a function can be arbitrarily
complex and nested; there could be dozens of points where a return value
is needed.
>>
>> In C on the other hand, the ':' of '?:' is always needed, even when it
>> is not expected to yield a value. Hence you often see this things like
>> this:
>>
>> p == NULL ? puts("error"): 0;
>
> Given that the tertiary operator chooses between two things, it seems
> fairly obvious that you need two alternatives to choose from - having a
> choice operator without at least two choices would be rather useless.
It seems you are just arguing in the defence of C rather than
objectively, and being contradictory in the process.
For example, earlier you said I'm wrong to insist on a default path for
multi-way ops when it is expected to yield a value. But here you say it
is 'obvious' for the ?: multi-way operator to insist on a default path
even when any value is not used.
This is on top of saying that I'm spreading 'FUD' about switch and that
is it really a perfectly straightforward feature!
Now *I* am wary of trusting your judgement.
> I can't say I have ever seen the tertiary operator used like this. There
> are a few C programmers that like to code with everything as
> expressions, using commas instead of semicolons, but they are IMHO
> mostly just being smart-arses. It's a lot more common to write :
>
> if (!p) puts("error");
Well, it happens, and I've seen it (and I've had to ensure my C compiler
deals with it when it comes up, which it has). Maybe some instances of
it are hidden behind macros.
>> Meanwhile I allow this (if I was keen on a compact form):
>>
>> (p = nil | print "error")
>>
>> No else is needed.
>>
>
> In C you could write :
>
> p == NULL || puts("error");
>
> which is exactly the same structure.
This is new to me. So this is another possibility for the OP?
It's an untidy feature however; it's abusing || in similar ways to those
who separate things with commas to avoid needing a compounds statement.
It is also error prone as it is untuitive: you probably meant one of:
p != NULL || puts("error");
p == NULL && puts("error");
There are also limitations: what follows || or || needs to be something
that returns a type that can be coerced to an 'int' type.
(Note that the '|' is my example is not 'or'; it means 'then':
( c | a ) # these are exactly equivalent
if c then a fi
( c | a | ) # so are these
if c then a else b fi
There is no restriction on what a and b are, statements or expressions,
unless the whole returns some value.)
> I think all of these, including your construct in your language, are
> smart-arse choices compared to a simple "if" statement, but personal
> styles and preferences vary.
C's if statement is rather limited. As it is only if-else, then
if-else-if sequences must be emulated using nested if-else-(if else (if
else....
Misleading indentation needs to be used to stop nested if's disappearing
to the right. When coding style mandates braces around if branches, an
exception needs to be made for if-else-if chains (otherwise you will end
up with }}}}}}}... at the end.
And the whole thing cannot return a value; a separate ?: feature (whose
branches must be expressions) is needed.
It is also liable to 'dangling' else, and error prone due to braces
being optional.
It's a mess. By contrast, my if statements look like this:
if then elsif then ... [else] fi
'elsif' is a part of the syntax. The whole thing can return a value.
There is a compact form (not for elsif, that would be too much) as shown
above.
[toc] | [prev] | [next] | [standalone]
| From | Tim Rentsch <tr.17687@z991.linuxsc.com> |
|---|---|
| Date | 2024-11-02 15:08 -0700 |
| Message-ID | <86v7x5thjt.fsf@linuxsc.com> |
| In reply to | #388810 |
Bart <bc@freeuk.com> writes:
> On 02/11/2024 11:41, David Brown wrote:
>
>> On 01/11/2024 20:47, Bart wrote:
>>
>>> On 01/11/2024 18:47, David Brown wrote:
>>>
>>>> On 01/11/2024 19:05, Bart wrote:
>>>>
>>>>> On 01/11/2024 17:35, David Brown wrote:
>>>
>>>>>>
>>>>>> What you have written here is all correct, but a more common
>>>>>> method would be to avoid having three printf's :
>>>>>>
>>>>>> void shout_a_number(int n) {
>>>>>> printf( (const char* []) { "ONE", "TWO", "THREE" } [n] );
>>>>>> }
>>>>>>
>>>>>> That's more likely to match what people would want.
>>>>>
>>>>> I was also trying to show that all elements are evaluated, so
>>>>> each has to have some side-effect to illustrate that.
>>>>
>>>> Fair enough.
>>>>
>>>>> A true N-way-select construct (C only really has ?:) would
>>>>> evaluate only one, and would deal with an out-of-range condition.
>>>>
>>>> That's a matter of opinion and design choice, rather than being
>>>> requirements for a "true" select construct.
>>>
>>> I don't think it's just opinion.
>>
>> Yes, it is.
I believe the phrase "N-way-select" would be understood by
most people to mean either exactly one or at most one out
of the N choices is put into effect. Saying it's just an
opinion is idiotic. We may not know how different people
would understand it, but how they understand it is something
that can be determined objectively, simply by asking them.
> Then we disagree on what 'multi-way' select might mean. I think it
> means branching, even if notionally, on one-of-N possible code paths.
>
> The whole construct may or may not return a value. If it does, then
> one of the N paths must be a default path.
Alternatively there could be an implicit default value. For
example, a hypothetical construct
( p; q; r; s; t )
where all of the variables are pointers, might return the first
pointer than is non-null, or a null pointer if all of them are
null (with an obvious generalization if the result expressions
and gating boolean expressions are distinct). Isn't this how
'cond' in Lisp works? Return the first expression whose guard
is non-nil, or nil if all the guards are nil.
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-03 01:26 +0100 |
| Message-ID | <6726C341.6030102@grunge.pl> |
| In reply to | #388810 |
Bart wrote:
> ...
as to this switch as i said the C jas some syntax that resembles switch
and it is
[2] { printf("one"), printf("two"), printf("three") }
i mean it is like this compound sometheng you posted
{ printf("one"), printf("two"), printf("three") } [2]
but with "key" on the left to ilustrate the analogy to
swich(n) {case 0: printf("one"); case 1: printf("two"); case 2:
rintf("three") }
imo the resemblance gives to think
the difference is this compound (array-like) example dont uses defined
keys so it semms some should be added
[n] {{1: printf("one")},{2: printf("two")},{3: printf("three")} }
so those deduction on switch gives the above imo
the question is if some things couldnt be ommitted for simplicity
[key] {'A': printf("one"); 'B': printf("two"); 'C': printf("three"}; }
something like that
(insted of
switch(key)
{
case 'A': printf("one"); break;
case 'B': printf("two"); break;
case 'C': printf("three"}; break;
}
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-03 12:03 +0000 |
| Message-ID | <vg7opm$bejq$2@dont-email.me> |
| In reply to | #388813 |
On 03/11/2024 00:26, fir wrote:
> Bart wrote:
>> ...
>
> as to this switch as i said the C jas some syntax that resembles switch
> and it is
>
> [2] { printf("one"), printf("two"), printf("three") }
>
> i mean it is like this compound sometheng you posted
>
> { printf("one"), printf("two"), printf("three") } [2]
>
> but with "key" on the left to ilustrate the analogy to
>
> swich(n) {case 0: printf("one"); case 1: printf("two"); case 2:
> rintf("three") }
>
> imo the resemblance gives to think
>
> the difference is this compound (array-like) example dont uses defined
> keys so it semms some should be added
>
> [n] {{1: printf("one")},{2: printf("two")},{3: printf("three")} }
>
> so those deduction on switch gives the above imo
>
> the question is if some things couldnt be ommitted for simplicity
>
> [key] {'A': printf("one"); 'B': printf("two"); 'C': printf("three"}; }
> something like that
>
> (insted of
>
> switch(key)
> {
> case 'A': printf("one"); break;
> case 'B': printf("two"); break;
> case 'C': printf("three"}; break;
> }
Here the switch looks clearer. Write it with 300 cases instead of 3,
then that becomes obvious.
The first time I wrote a big C program, I used a syntax like this:
switch (x)
when 'A', 'B' then printf("one")
when 'C' then printf("two")
else printf("three")
endsw
This needed to be converted to normal C before compiling, but the macro
system wasn't quite up to the job (making using gnu C which allows for
lists of case labels).
Instead I used a script to do the conversion, which needed 1:1 line
correspondence. The result was something like this:
switch (x) {
break; case 'A': case 'B': printf("one");
break; case 'C': printf("two");
break; default: printf("three");
}
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-03 14:39 +0100 |
| Message-ID | <bf4e50819b1dcac5e7f689ad10b3a82e8fc82047@i2pn2.org> |
| In reply to | #388818 |
Bart wrote:
> On 03/11/2024 00:26, fir wrote:
>> Bart wrote:
>>> ...
>>
>> as to this switch as i said the C jas some syntax that resembles
>> switch and it is
>>
>> [2] { printf("one"), printf("two"), printf("three") }
>>
>> i mean it is like this compound sometheng you posted
>>
>> { printf("one"), printf("two"), printf("three") } [2]
>>
>> but with "key" on the left to ilustrate the analogy to
>>
>> swich(n) {case 0: printf("one"); case 1: printf("two"); case 2:
>> rintf("three") }
>>
>> imo the resemblance gives to think
>>
>> the difference is this compound (array-like) example dont uses defined
>> keys so it semms some should be added
>>
>> [n] {{1: printf("one")},{2: printf("two")},{3: printf("three")} }
>>
>> so those deduction on switch gives the above imo
>>
>> the question is if some things couldnt be ommitted for simplicity
>>
>> [key] {'A': printf("one"); 'B': printf("two"); 'C': printf("three"}; }
>
>
>> something like that
>>
>> (insted of
>>
>> switch(key)
>> {
>> case 'A': printf("one"); break;
>> case 'B': printf("two"); break;
>> case 'C': printf("three"}; break;
>> }
>
>
> Here the switch looks clearer. Write it with 300 cases instead of 3,
> then that becomes obvious.
>
depend on what some understoods by clearer - imo not
this []{;;;} at least is like logically drawed from other c syntax
and switch case overally the word case is ok imo but the word switch is
overrally like wrong imo switch could be better replaced by two
word "select" and maybe "goto" as this swich that selects could use
select and this one wgo does goto could use word goto
goto key;
'A': printf("a");
'B': printf("b");
'C': printf("c");
'
overally thete is lso possibility to do it such way
void foo()
{
"a" { printf("aaa"); } //definitions not calls itself
"b" { printf("bbb"); }
"c" { printf("ccc"); }
"a";"b";"c"; //calls (???)
// would need maybe some some syntax to call it (many could be chosen)
// "a"() ? foo."a" ? foo.[key] ?
maybe this woudl be the best if established as ths is more syntaktc "low
lewel"
}
> The first time I wrote a big C program, I used a syntax like this:
>
> switch (x)
> when 'A', 'B' then printf("one")
> when 'C' then printf("two")
> else printf("three")
> endsw
>
> This needed to be converted to normal C before compiling, but the macro
> system wasn't quite up to the job (making using gnu C which allows for
> lists of case labels).
>
> Instead I used a script to do the conversion, which needed 1:1 line
> correspondence. The result was something like this:
>
> switch (x) {
> break; case 'A': case 'B': printf("one");
> break; case 'C': printf("two");
> break; default: printf("three");
> }
>
>
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-03 15:17 +0100 |
| Message-ID | <3b3facef6fdb6ad4edb2989a0a18fd2f2526c536@i2pn2.org> |
| In reply to | #388819 |
fir wrote:
> Bart wrote:
>> On 03/11/2024 00:26, fir wrote:
>>> Bart wrote:
>>>> ...
>>>
>>> as to this switch as i said the C jas some syntax that resembles
>>> switch and it is
>>>
>>> [2] { printf("one"), printf("two"), printf("three") }
>>>
>>> i mean it is like this compound sometheng you posted
>>>
>>> { printf("one"), printf("two"), printf("three") } [2]
>>>
>>> but with "key" on the left to ilustrate the analogy to
>>>
>>> swich(n) {case 0: printf("one"); case 1: printf("two"); case 2:
>>> rintf("three") }
>>>
>>> imo the resemblance gives to think
>>>
>>> the difference is this compound (array-like) example dont uses defined
>>> keys so it semms some should be added
>>>
>>> [n] {{1: printf("one")},{2: printf("two")},{3: printf("three")} }
>>>
>>> so those deduction on switch gives the above imo
>>>
>>> the question is if some things couldnt be ommitted for simplicity
>>>
>>> [key] {'A': printf("one"); 'B': printf("two"); 'C': printf("three"}; }
>>
>>
>>> something like that
>>>
>>> (insted of
>>>
>>> switch(key)
>>> {
>>> case 'A': printf("one"); break;
>>> case 'B': printf("two"); break;
>>> case 'C': printf("three"}; break;
>>> }
>>
>>
>> Here the switch looks clearer. Write it with 300 cases instead of 3,
>> then that becomes obvious.
>>
>
> depend on what some understoods by clearer - imo not
>
> this []{;;;} at least is like logically drawed from other c syntax
>
> and switch case overally the word case is ok imo but the word switch is
> overrally like wrong imo switch could be better replaced by two
> word "select" and maybe "goto" as this swich that selects could use
> select and this one wgo does goto could use word goto
>
> goto key;
> 'A': printf("a");
> 'B': printf("b");
> 'C': printf("c");
> '
>
> overally thete is lso possibility to do it such way
>
> void foo()
> {
>
> "a" { printf("aaa"); } //definitions not calls itself
> "b" { printf("bbb"); }
> "c" { printf("ccc"); }
>
>
> "a";"b";"c"; //calls (???)
> // would need maybe some some syntax to call it (many could be chosen)
>
> // "a"() ? foo."a" ? foo.[key] ?
>
> maybe this woudl be the best if established as ths is more syntaktc "low
> lewel"
>
> }
>
the calling sign shuld be needed as as for years i wanted to do
something like
void foo()
{
a {/**/}
b {/**/}
c {/**/}
a;b;b;c; //calls a calls b twice calls c
}
( you can alse make expressions of it a+b*c (where a,b,c are code blocks)
then if using
1 {/**/}
2 {/**/}
3 {/**/}
"A" {/**/}
"B" {/**/}
"CCC" {/**/}
it would clash with normal usage
lika printf("CCC");
so some operator to call it is needed (and it could wrk as swich if you
allow to call it on variable not immediate value
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-03 02:21 +0100 |
| Message-ID | <6726D029.1010809@grunge.pl> |
| In reply to | #388810 |
Bart wrote:
>
> It's a mess. By contrast, my if statements look like this:
>
> if then elsif then ... [else] fi
>
>
> 'elsif' is a part of the syntax. The whole thing can return a value.
> There is a compact form (not for elsif, that would be too much) as shown
> above.
as to if when thinking of it the if construct has such parts
if X then S else E
and the keyword if is not necessary imo as the expression x return
logical value them then can be used on this without if
X then {}
X else {}
i would prefer to denote (at least temporerely) then as ->
and else as ~> then you can build construct like
a -> b -> c -> d ~> e ~> f
when the arrows take logical value of the left
(if a true then b, if be true then c if c true then d,if
d false then e and if e false then f)
but some need also to use else to some previous espression and
i think how it could be done but maybe just parenthesis can be used
a (->b->c) ~>z
if a true then b and if b true then c but if a false then z
[toc] | [prev] | [next] | [standalone]
| From | Bart <bc@freeuk.com> |
|---|---|
| Date | 2024-11-03 11:47 +0000 |
| Message-ID | <vg7nst$bejq$1@dont-email.me> |
| In reply to | #388815 |
On 03/11/2024 01:21, fir wrote:
> Bart wrote:
>>
>> It's a mess. By contrast, my if statements look like this:
>>
>> if then elsif then ... [else] fi
>>
>>
>> 'elsif' is a part of the syntax. The whole thing can return a value.
>> There is a compact form (not for elsif, that would be too much) as shown
>> above.
>
>
> as to if when thinking of it the if construct has such parts
>
> if X then S else E
>
> and the keyword if is not necessary imo as the expression x return
> logical value them then can be used on this without if
>
> X then {}
> X else {}
>
> i would prefer to denote (at least temporerely) then as ->
> and else as ~> then you can build construct like
>
>
> a -> b -> c -> d ~> e ~> f
>
> when the arrows take logical value of the left
> (if a true then b, if be true then c if c true then d,if
> d false then e and if e false then f)
>
> but some need also to use else to some previous espression and
> i think how it could be done but maybe just parenthesis can be used
>
> a (->b->c) ~>z
>
> if a true then b and if b true then c but if a false then z
C already has this (I've added parentheses for clarity):
(a ? (b ? c : -) : z)
This shows you haven't provided a branch for b being false.
Also it's not clear if you intended for b to be evaluated twice; I've
assumed only once as it is nonsense otherwise.
[toc] | [prev] | [next] | [standalone]
| From | fir <fir@grunge.pl> |
|---|---|
| Date | 2024-11-03 14:46 +0100 |
| Message-ID | <b528469f59b9c062e03db14790137424c56c36fa@i2pn2.org> |
| In reply to | #388817 |
Bart wrote:
> On 03/11/2024 01:21, fir wrote:
>> Bart wrote:
>>>
>>> It's a mess. By contrast, my if statements look like this:
>>>
>>> if then elsif then ... [else] fi
>>>
>>>
>>> 'elsif' is a part of the syntax. The whole thing can return a value.
>>> There is a compact form (not for elsif, that would be too much) as shown
>>> above.
>>
>>
>> as to if when thinking of it the if construct has such parts
>>
>> if X then S else E
>>
>> and the keyword if is not necessary imo as the expression x return
>> logical value them then can be used on this without if
>>
>> X then {}
>> X else {}
>>
>> i would prefer to denote (at least temporerely) then as ->
>> and else as ~> then you can build construct like
>>
>>
>> a -> b -> c -> d ~> e ~> f
>>
>> when the arrows take logical value of the left
>> (if a true then b, if be true then c if c true then d,if
>> d false then e and if e false then f)
>>
>> but some need also to use else to some previous espression and
>> i think how it could be done but maybe just parenthesis can be used
>>
>> a (->b->c) ~>z
>>
>> if a true then b and if b true then c but if a false then z
>
>
> C already has this (I've added parentheses for clarity):
>
> (a ? (b ? c : -) : z)
>
> This shows you haven't provided a branch for b being false.
>
coz ypu dont need to provide such branch
in c yu need to put that ":" each time? (if so some error was discovered
as it ould be better to not oblige its existence)
> Also it's not clear if you intended for b to be evaluated twice; I've
> assumed only once as it is nonsense otherwise.
>
why twice? -> just goes forward on true and ~> goes forward on fales
a (->b ->c) ~>z
a is checked if true b is called if b is true c is called, if a was
false z is called (eveluated)
[toc] | [prev] | [next] | [standalone]
Page 3 of 14 — ← Prev page 1 2 [3] 4 5 … 14 Next page →
Back to top | Article view | comp.lang.c
csiph-web