Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.c > #402647 > unrolled thread

Taming The Switch-Statement

Back to article view | Back to comp.lang.c

Contents

  Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-03 08:43 +0000
    Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 11:24 +0100
      Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 22:15 +0000
    Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-03 14:22 +0200
    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-03 18:02 +0200
      Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:24 +0800
      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-03 17:36 +0100
        Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-03 16:31 -0700
          Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-04 10:23 +0200
          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 12:18 +0100
          Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:20 +0200
            Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:34 +0000
              Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:04 -0700
        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 16:18 +0200
          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 16:09 +0100
            Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 16:59 +0000
              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 18:30 +0100
                Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-04 19:49 +0100
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 20:35 +0100
                    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-04 22:27 +0200
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-04 22:47 +0100
                  Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-04 21:59 +0000
        Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-04 23:38 +0000
          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:24 +0100
            Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:48 +0000
              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 00:11 +0100
                Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 09:49 +0200
                  Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 11:12 +0200
                    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:41 +0200
                      Re: Taming The Switch-Statement Richard Harnden <richard.nospam@gmail.invalid> - 2026-10-06 12:33 +0100
                        Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:16 +0100
                          Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:37 +0000
                            Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 17:27 +0100
                              Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-06 23:14 +0000
                                Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 01:25 +0100
                                  Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 04:19 +0000
                                    Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-07 06:28 +0000
                                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:39 +0100
                                        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 12:57 +0200
                                    Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:32 +0100
                                      Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-07 15:10 +0000
                                        Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 19:41 +0100
                                          Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-08 04:49 +0000
                                            Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-08 12:24 +0100
                                  Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 09:07 +0200
                                    Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 11:49 +0100
                                      Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 13:11 +0200
                        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 16:17 +0200
                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 15:32 +0100
                            Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:25 +0200
                          Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:39 +0000
                            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:48 +0200
                              Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 18:12 +0000
                                [OT] substances (was Re: Taming The Switch-Statement) Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:50 +0200
                                Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:06 -0700
                      Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 19:25 +0200
                        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:28 +0200
                          Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-07 15:16 +0200
                            Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 16:40 +0200
                            Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-08 07:24 -0700
                      Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:08 -0700
                        Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 23:45 +0000
                          Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 17:08 -0700
                          Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-07 10:35 +0200
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-06 12:33 +0100
                    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:16 +0200
                    Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 16:41 -0700
                Re: Taming The Switch-Statement tTh <tth@none.invalid> - 2026-10-06 12:14 +0200
                  Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 12:43 +0200
                Re: Taming The Switch-Statement Jim Jackson <jj@franjam.org.uk> - 2026-10-06 11:47 +0000
                Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-06 16:05 -0700
                Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-07 00:42 +0000
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 13:52 +0100
                    Re: Taming The Switch-Statement "Chris M. Thomasson" <chris.m.thomasson.1@gmail.com> - 2026-10-07 14:06 -0700
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-07 23:31 +0100
        Re: Taming The Switch-Statement Kaz Kylheku <046-301-5902@kylheku.com> - 2026-10-05 21:32 +0000
          Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 06:07 +0800
          Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 16:42 -0700
            Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-05 18:05 -0700
              Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 09:04 +0200
                Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:11 -0700
                  Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-06 21:40 +0200
              Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 00:59 -0700
                Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-06 08:16 +0000
                  Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-06 04:21 -0700
            Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-06 14:43 +0000
              Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-06 17:36 +0200
        Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-06 20:36 -0700
    Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-04 00:20 +0800
    Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 09:05 -0700
      Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-04 23:44 +0000
        Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 01:46 +0100
          Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-04 20:48 -0700
            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-05 06:24 +0200
          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-05 11:09 +0100
          Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:22 +0800
            Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-06 05:26 +0800
    Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 00:25 +0000
      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 01:58 +0100
        Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-09 19:17 -0700
          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 11:53 +0100
            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 14:01 +0200
              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 14:11 +0100
                Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:34 +0800
                  Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-10 21:58 +0800
                Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-10 17:50 +0200
                  Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 05:52 +0000
                    Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:16 +0000
                      Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 23:38 +0000
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 11:58 +0100
                    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 14:42 +0200
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:39 +0100
                        Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 15:35 -0700
                    Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 14:42 +0000
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 17:23 +0100
                        Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 17:48 +0000
                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 19:10 +0100
                            Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-12 07:01 +0000
                    Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 16:41 +0100
                Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:08 +0200
                  Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:02 +0300
                    Re: Taming The Switch-Statement cross@spitfire.i.gajendra.net (Dan Cross) - 2026-10-10 19:03 +0000
                      Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 22:29 +0300
                    Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 21:55 +0200
                      Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 23:03 +0300
                        Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 22:33 +0200
                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:53 +0100
                            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:16 +0200
                            Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-11 15:29 +0000
                          Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-10 15:30 -0700
                            Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-10 22:58 +0000
                              Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:09 +0800
                                Re: Taming The Switch-Statement ram@zedat.fu-berlin.de (Stefan Ram) - 2026-10-11 10:14 +0000
                                  Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:12 +0000
                            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:58 +0200
                          Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:32 -0700
                            Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-11 01:58 +0300
                              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 01:43 +0100
                            Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:12 +0800
                            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 04:07 +0200
                              Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 20:13 -0700
                                Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:36 +0200
                        Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 04:26 -0700
                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 13:35 +0100
                            Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-11 06:13 -0700
                              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 14:51 +0100
                            Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 15:33 +0200
                              Re: Taming The Switch-Statement Andrey Tarasevich <noone@noone.net> - 2026-10-11 09:01 -0700
                                Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 19:17 +0200
                                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 18:57 +0100
                                    Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:28 -0700
                                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:02 +0100
                                        Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 16:29 -0700
                                      Re: Taming The Switch-Statement Tim Rentsch <tr.17687@z991.linuxsc.com> - 2026-10-12 04:03 -0700
                                    Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:05 +0200
                                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 14:37 +0100
                                        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:12 +0200
                                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:32 +0100
                    Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:38 -0700
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 21:09 +0100
                    Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 23:14 +0200
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-10 23:01 +0100
                      Re: Taming The Switch-Statement antispam@fricas.org (Waldek Hebisch) - 2026-10-11 08:00 +0000
                        Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:27 +0200
                          Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 10:49 +0200
            Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:30 -0700
              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 02:12 +0100
                Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 19:55 -0700
                  Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 11:00 +0200
                  Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 12:21 +0100
                    Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-11 14:04 -0700
                      Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 23:05 +0100
                        Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 07:22 +0200
                          Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 11:42 +0100
                            Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-12 16:15 +0200
                            Re: Taming The Switch-Statement scott@slp53.sl.home (Scott Lurndal) - 2026-10-12 14:34 +0000
                              Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-12 16:47 +0100
                                Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-13 00:15 +0800
                Re: Taming The Switch-Statement bart <bc@freeuk.com> - 2026-10-11 22:36 +0100
          Re: Taming The Switch-Statement gazelle@shell.xmission.com (Kenny McCormack) - 2026-10-10 13:14 +0000
          Re: Taming The Switch-Statement Michael S <already5chosen@yahoo.com> - 2026-10-10 19:50 +0300
            Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-10 20:13 +0200
              Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 15:54 -0700
                Re: Taming The Switch-Statement Janis Papanagnou <janis_papanagnou+ng@hotmail.com> - 2026-10-11 03:41 +0200
                  Re: Taming The Switch-Statement Johann 'Myrkraverk' Oskarsson <johann@myrkraverk.invalid> - 2026-10-11 09:51 +0800
                  Re: Taming The Switch-Statement David Brown <david.brown@hesbynett.no> - 2026-10-11 11:41 +0200
            Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:44 -0700
          Re: Taming The Switch-Statement Keith Thompson <Keith.S.Thompson+u@gmail.com> - 2026-10-10 16:56 -0700
      Re: Taming The Switch-Statement Lawrence D’Oliveiro <ldo@nz.invalid> - 2026-10-11 21:26 +0000
        Re: Taming The Switch-Statement Jon Ribbens <jon+usenet@unequivocal.eu> - 2026-10-11 22:12 +0000

Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10  Next page →

#402743

Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
> On 2026-10-06 03:05, Keith Thompson wrote:
>> [...]
>> A weird but mostly harmless consequence of this is that C23 keeps
>> the syntactic construct of a *labeled-statement*, but it's used
>> extremely rarely.  Any C17-or-earlier labeled-statement at the
>> top level of an enclosing compound-statement is no longer a C23
>> labeled-statement, even though it looks like one.  In C23, a
>> labeled-statement can only occur in an odd construct like this:
>>      if (condition)
>>          LABEL: statement;
>
> You've been arguing on the implicit difference in the language
> definition here. That's all a fine explanation.
>
> What I wonder about is what you find "odd" with that construct.
> For folks who use jumps and labels (not me) that looks not too
> odd to me; I can imagine programming cases where that may be
> useful.

It's unlikely that I'd write something like that.  If I did,
I'd use braces:

    if (condition) {
        LABEL: statement;
    }

I'm sometimes willing to omit optional braces, but almost exclusively
in cases where the entire construct is on one line:

    if (condition) statement;

Aside from that, writing an if statement and providing a way to bypass
the test feels odd (to me).  Presumably there's a `goto LABEL;`
elsewere in the same function.  I'd look for a clearer way to structure
the code.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#402761

On 2026-10-06 13:11, Keith Thompson wrote:
> Janis Papanagnou <janis_papanagnou+ng@hotmail.com> writes:
>> On 2026-10-06 03:05, Keith Thompson wrote:
>>> [...]
>>> A weird but mostly harmless consequence of this is that C23 keeps
>>> the syntactic construct of a *labeled-statement*, but it's used
>>> extremely rarely.  Any C17-or-earlier labeled-statement at the
>>> top level of an enclosing compound-statement is no longer a C23
>>> labeled-statement, even though it looks like one.  In C23, a
>>> labeled-statement can only occur in an odd construct like this:
>>>       if (condition)
>>>           LABEL: statement;
>>
>> You've been arguing on the implicit difference in the language
>> definition here. That's all a fine explanation.
>>
>> What I wonder about is what you find "odd" with that construct.
>> For folks who use jumps and labels (not me) that looks not too
>> odd to me; I can imagine programming cases where that may be
>> useful.
> 
> It's unlikely that I'd write something like that.  If I did,
> I'd use braces:
> 
>      if (condition) {
>          LABEL: statement;
>      }

That's actually something I'd be suspicious about; i.e. jumping into a
brace-enclosed region. This uncertainty stems from my ignorance on the
C-standard concerning that case, for sure. In other languages it's not
generally allowed to jump into such blocks. Without the braces, OTOH,
the scope rules are more obvious. That's why I think it makes sense to
allow such a labelled single statement and not require to set spurious
braces as a special case (that normally isn't required).

The application cases I said I could imagine are like, say,

   if (c1) { ... ; if (c12) goto LABEL; }
   ...
   if (c2) { ... ; goto LABEL; }
   ...
   if (c3)
       LABEL: finalize();

> 
> I'm sometimes willing to omit optional braces, but almost exclusively
> in cases where the entire construct is on one line:
> 
>      if (condition) statement;

I do the same but mostly only in cascaded 'if's. It depends on context.

> 
> Aside from that, writing an if statement and providing a way to bypass
> the test feels odd (to me).  Presumably there's a `goto LABEL;`
> elsewere in the same function.  I'd look for a clearer way to structure
> the code.

Yeah, same here; as said, I'm regularly not using a goto/label but the
above quoted code pattern seems not unreasonable to me.

Janis

[toc] | [prev] | [next] | [standalone]

#402735

On Mon 10/5/2026 6:05 PM, Keith Thompson wrote:
> Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
> In C23, a
> labeled-statement can only occur in an odd construct like this:
> 
>      if (condition)
>          LABEL: statement;
> 
...and as another example of the same thing, while this

   switch (0)
   {
     case 0: int a = printf("Hello World\n");
   }

is now valid in C23, this

   switch (0)
     case 0: int a = printf("Hello World\n");

remains invalid.

--
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#402738

On Tue, 6 Oct 2026 00:59:40 -0700, Andrey Tarasevich wrote:

> ... this
> 
>    switch (0)
>      case 0: int a = printf("Hello World\n");
> 
> remains invalid.

I showed how to do that in my example.

[toc] | [prev] | [next] | [standalone]

#402744

Lawrence D’Oliveiro <ldo@nz.invalid> writes:
> On Tue, 6 Oct 2026 00:59:40 -0700, Andrey Tarasevich wrote:
>> ... this
>> 
>>    switch (0)
>>      case 0: int a = printf("Hello World\n");
>> 
>> remains invalid.
>
> I showed how to do that in my example.

If by "that" you mean having a case label followed by a declaration, I
don't believe you did.  You've posted twice in this thread, including
your post that started it.  In your original post, all the case
labels were on ordinary (possibly compound) statements.

In any case, (a) the solution is obvious (add braces), and (b) I
don't believe anyone was looking for a way to do that in the first
place, just commenting on what is and isn't valid.

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

#402753

Keith Thompson <Keith.S.Thompson+u@gmail.com> writes:
>Kaz Kylheku <046-301-5902@kylheku.com> writes:
>> On 2026-10-03, bart <bc@freeuk.com> wrote:
>>> On 03/10/2026 17:02, David Brown wrote:
>[...]
>>>> gcc -Werror=implict-fallthrough
>>>
>>> I assume this is for non-empty blocks? Otherwise this will be an error:
>>>
>>>     case 'A': case 'B': case 'C':
>>>        // deal with ABC
>>
>> Note that syntactically:
>>
>>    case 'A': case 'B': case 'C': ;  // note semicolon
>>
>> are a nested case statement, and not consecutive statement
>> syntax.
>
>More precisely, it's a single labeled-statement.  Breaking it down
>according to the grammar:
>
>    ;                                 is a null statement
>    case 'C': ;                       is a labeled-statement
>    case 'B': case 'C': ;             is a labeled-statement
>    case 'A': case 'B': case 'C': ;   is a labeled-statement
>
>Terminology aside, you're right.  I've always thought of the three
>case labels as three separate targets, with the switch statement
>jumping to case 'A', for example, and falling through the others,
>but that's not the best way to think about it.

Indeed.  And in this particular case, gcc/clang have an useful extension.

   case 'A' ... 'C':

Has there been any attempts to add that to the C standard?

[toc] | [prev] | [next] | [standalone]

#402756

On 06/10/2026 16:43, Scott Lurndal wrote:

> Indeed.  And in this particular case, gcc/clang have an useful extension.
> 
>     case 'A' ... 'C':
> 
> Has there been any attempts to add that to the C standard?

I believe they are included in the next C standard (currently labelled C2y).


<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3886.pdf>

<https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3370.htm>

[toc] | [prev] | [next] | [standalone]

#402776

On Sat 10/3/2026 9:36 AM, bart wrote:
> On 03/10/2026 17:02, David Brown wrote:
>> On 03/10/2026 10:43, Lawrence D’Oliveiro wrote:
>>> How not to forget to end each case-sequence in a switch statement with
>>> a break-statement: put the break at the same indentation level as the
>>> case-clause as well as the switch-expression. That way, you can scan
>>> your eye down a single line for each switch-statement to be sure that
>>> no breaks are missing. A reasonably-complex example, with a nested
>>> switch for added interest:
>>>
>>
>> gcc -Werror=implict-fallthrough
> 
> 
> I assume this is for non-empty blocks? Otherwise this will be an error:
> 
>     case 'A': case 'B': case 'C':
>        // deal with ABC
This is not, but in other cases there are still some differences between 
implementations.

For example, Clang approaches this matter rather formally. This:

   switch (0)
   {
     case 0:;
     case 1:;
     case 2:;
   }

is already sufficient to trigger fallthrough warnings in Clang under 
`-Wimplicit-fallthrough`, even tough all "blocks" in the above are empty 
for all practical means and purposes.

GCC will remain silent for the above code. This will keep it silent as well:

   switch (0)
   {
     case 0:;
     case 1:;
     case 2: printf("World");
   }

This produces no warnings either:

   switch (0)
   {
     case 0: printf("Hello ");
     case 1:;
     case 2:;
   }

And finally this:

   switch (0)
   {
     case 0: printf("Hello ");
     case 1:;
     case 2: printf("World");
   }

will trigger a warning under `-Wimplicit-fallthrough`. So, GCC appears 
to look for a fallthrough from a non-empty to a non-empty before it warns.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#402653

On 10/3/2026 4:43 PM, Lawrence D’Oliveiro wrote:
> How not to forget to end each case-sequence in a switch statement with
> a break-statement: put the break at the same indentation level as the
> case-clause as well as the switch-expression. That way, you can scan
> your eye down a single line for each switch-statement to be sure that
> no breaks are missing. A reasonably-complex example, with a nested
> switch for added interest:
Dear Lawrence,

I don't know about you, but I tend to use my eyes.  I grew up with
coding on basic tools, and have never felt a /need/ for a fancy text
editor, so I have not created some code verifier nor Emacs skeleton
for this yet.

So what I do is to code the switch statement something like

   switch ( foo ) {
   case BAR: {
     /* ... */
   } break ;
   case BAZ: {
     /* ... */
   } break ;
   }

and put the /break/ keyword outside the curly braces for easy visual in-
spection, no matter if the text editor has syntax highlight turned on or
not.  The above is somewhat reminiscent of reality, as Emacs CC-mode is
rather idiotic at indenting this kind of code, and I have not bothered
to tame it myself.


What do you think?  Doesn't this make it rather easy to see whether each
{ } ends with a break?
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402674

On Sat 10/3/2026 1:43 AM, Lawrence D’Oliveiro wrote:
> How not to forget to end each case-sequence in a switch statement with
> a break-statement: put the break at the same indentation level as the
> case-clause as well as the switch-expression. 
I usually employ a much better method, which should really be included 
into every coding standard: just interlace your switch statement with a 
dummy if-else ladder. This will effectively provide an implicit 
automatic "break" at the end of each 'case' section

   #include <stdio.h>
   #include <stdlib.h>

   int main(void)
   {
     for (unsigned n = 100; n > 0; --n)
     {
       switch (rand() % 4)
       {
         if (0) {
         case 0:
           printf("Case zero");
         } else  if (0) {
         case 1:
           printf("Case one");
         } else  if (0) {
         case 2:
           printf("Case two");
         } else  if (0) {
         case 3:
           printf("Case three");
         }
         printf("\n");
       }
     }
   }

It might look a bit cluttered and convoluted at first, but with everyday 
intensive use it quickly becomes a second nature. Makes a great 
conversation topic around the watering hole, BTW. Your colleagues will 
appreciate the inherent safety of the approach.

--
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#402686

On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:

> I usually employ a much better method, which should really be
> included into every coding standard: just interlace your switch
> statement with a dummy if-else ladder.

The more code you have to write, the more opportunities there are to
get things wrong. And maintenance takes more work, too.

> It might look a bit cluttered and convoluted at first, but with
> everyday intensive use it quickly becomes a second nature.

*Writing* it may become “second nature”, but *reading* it never will.

[toc] | [prev] | [next] | [standalone]

#402690

On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
> 
>> I usually employ a much better method, which should really be
>> included into every coding standard: just interlace your switch
>> statement with a dummy if-else ladder.
> 
> The more code you have to write, the more opportunities there are to
> get things wrong. And maintenance takes more work, too.
> 

I don't know if AT was being serious. This was the proposal:

   for (unsigned n = 100; n > 0; --n)
     {
       switch (rand() % 4)
       {
         if (0) {
         case 0:
           printf("Case zero");
         } else  if (0) {
         case 1:
           printf("Case one");
         } else  if (0) {
         case 2:
           printf("Case two");
         } else  if (0) {
         case 3:
           printf("Case three");
         }
         printf("\n");
       }
     }
   }


It looks more of a mess than just writing the breaks. And there is 
something funny about it: that final 'printf' is inside the switch's 
compound statement, and here it is executed after any of the 4 cases.

Without the if-ladder, it would have to go outside the compound 
statement. So it changes the behaviour subtly.

Here is the same functionality as above, using my everyday language:

     to 100 do
         switch rand() rem 4
         when 0 then print "Case zero"
         when 1 then print "Case one"
         when 2 then print "Case two"
         when 3 then print "Case three"
         end
         println
     end

There is little clutter and little ambiguity. This is why syntax is 
important including doing 'switch' properly.


For a fairer comparison, here is more idiomatic C:

   for (unsigned n = 100; n > 0; --n)
     {
       switch (rand() % 4) {
         case 0:
           printf("Case zero");
           break;
         case 1:
           printf("Case one");
           break;
         case 2:
           printf("Case two");
           break;
         case 3:
           printf("Case three");
           break;
       }
       printf("\n");
     }

Needing those breaks makes it harder to inline the cases and printfs.

[toc] | [prev] | [next] | [standalone]

#402696

On Sun 10/4/2026 5:46 PM, bart wrote:
> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
>> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>>
>>> I usually employ a much better method, which should really be
>>> included into every coding standard: just interlace your switch
>>> statement with a dummy if-else ladder.
>>
>> The more code you have to write, the more opportunities there are to
>> get things wrong. And maintenance takes more work, too.
>>
> 
> I don't know if AT was being serious. 

I wasn't, of course.

> It looks more of a mess than just writing the breaks. And there is 
> something funny about it: that final 'printf' is inside the switch's 
> compound statement, and here it is executed after any of the 4 cases.

Hm... It wasn't intentional. But it's pretty cool nevertheless.

I intended the final `printf` to be a part of `for`s compound statement, 
but not a part of `switch`s. But by making this little mistake I purely 
accidentally "created" another interesting control structure: something 
like a final clause for every `case` branch, which is executed after 
each one of them.

See, the beauty of this approach? Even an accidental glitch leads to 
something profoundly ingenious.

-- 
Best regards,
Andrey

[toc] | [prev] | [next] | [standalone]

#402697

On 2026-10-05 05:48, Andrey Tarasevich wrote:
> [...]
> 
> I intended the final `printf` to be a part of `for`s compound statement, 
> but not a part of `switch`s. But by making this little mistake I purely 
> accidentally "created" another interesting control structure: something 
> like a final clause for every `case` branch, which is executed after 
> each one of them.

Actually a consequence of the low-level nature of how the switch with
its labels is defined. Such things have been seen since Duff's Device.
(Or maybe even earlier?)

> 
> See, the beauty of this approach? Even an accidental glitch leads to 
> something profoundly ingenious.

Sort of. :-)  It's at least fancy what "C" all allows to convolute code.

But the code does that fancy stuff only because there's no 'break' or
[here equivalently] the 'if's final [missing] 'else'. A bit much effort
for something that can in a clearer form be implemented without all the
"if (0)". ;-)

It was obvious that your code wasn't meant to be serious. It's less
obvious (to me) whether you really find that "profoundly ingenious".

Janis

[toc] | [prev] | [next] | [standalone]

#402703

On 05/10/2026 01:46, bart wrote:
> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:


> Here is the same functionality as above, using my everyday language:
> 
>      to 100 do
>          switch rand() rem 4
>          when 0 then print "Case zero"
>          when 1 then print "Case one"
>          when 2 then print "Case two"
>          when 3 then print "Case three"
>          end
>          println
>      end
> 
> There is little clutter and little ambiguity. This is why syntax is 
> important including doing 'switch' properly.

Since this syntax is expression-based, it can also be rearranged like this:

     to 100 do
         println "Case", (rand() rem 4 | "one", "two", "three" | "zero")
     end

But then, C can also manage a one-liner for the body:

     int n = 100; while (n--)
         printf("Case %s\n", (char*[4]){"zero", "one", "two", 
"three"}[rand() % 4]);

Not bad, but it uses ~39 tokens (not counting the two inside the format 
string), while mine has 22 tokens (with mine even token counting is 
easier!).

There is a big difference though: C effectively evaluates all elements 
of that list. It won't actually do that here, but in this form:

         (char*[4]){f0(), f1(), f2(), f3()}[rand() % 4]

then all functions are called each time.

In my version, it's not a list, but N-way selection, a form of switch, 
and only one element is evaluated. Since the whole returns a value, an 
'else' branch is needed (the bit with "zero"). Note this is 1-based.

(If the index was to be out of bounds, say 'rand() % 8' was used, then C 
would have UB. In my version, that is detected, and the 'else' branch 
returned.)

 >> The more code you have to write, the more opportunities there are to
 >> get things wrong. And maintenance takes more work, too.

[toc] | [prev] | [next] | [standalone]

#402713

On 10/5/2026 8:46 AM, bart wrote:
> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
>> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>>
>>> I usually employ a much better method, which should really be
>>> included into every coding standard: just interlace your switch
>>> statement with a dummy if-else ladder.
>>
>> The more code you have to write, the more opportunities there are to
>> get things wrong. And maintenance takes more work, too.
>>
> 
> I don't know if AT was being serious. This was the proposal:
> 
>    for (unsigned n = 100; n > 0; --n)
>      {
>        switch (rand() % 4)
>        {
>          if (0) {
>          case 0:
>            printf("Case zero");
>          } else  if (0) {
>          case 1:
>            printf("Case one");
>          } else  if (0) {
>          case 2:
>            printf("Case two");
>          } else  if (0) {
>          case 3:
>            printf("Case three");
>          }
>          printf("\n");
>        }
>      }
>    }
> 
> 
> It looks more of a mess than just writing the breaks. And there is 
> something funny about it: that final 'printf' is inside the switch's 
> compound statement, and here it is executed after any of the 4 cases.
> 
> Without the if-ladder, it would have to go outside the compound 
> statement. So it changes the behaviour subtly.
> 
> Here is the same functionality as above, using my everyday language:
> 
>      to 100 do
>          switch rand() rem 4
>          when 0 then print "Case zero"
>          when 1 then print "Case one"
>          when 2 then print "Case two"
>          when 3 then print "Case three"
>          end
>          println
>      end
> 
> There is little clutter and little ambiguity. This is why syntax is 
> important including doing 'switch' properly.
> 
> 
> For a fairer comparison, here is more idiomatic C:
> 
>    for (unsigned n = 100; n > 0; --n)
>      {
>        switch (rand() % 4) {
>          case 0:
>            printf("Case zero");
>            break;
>          case 1:
>            printf("Case one");
>            break;
>          case 2:
>            printf("Case two");
>            break;
>          case 3:
>            printf("Case three");
>            break;
>        }
>        printf("\n");
>      }
> 
> Needing those breaks makes it harder to inline the cases and printfs.

Oh, it's not hard at all.  What you do to put everything in a single
line, is to wrap the whole thing an a function, then you can just return
the value of the printf(), and no error code is lost.

   for ( signed n = 100 ; n > 0 ; n-- ) switch ( n ) {
     /* Gets rid of the superfluous curlies before the switch.  */
     case 0: return printf( "case zero" ) ;
     case 1: return printf( "case one" ) ;
     case 2: return printf( "case two" ) ;
     case 3: return printf( "case three" ) ;
   }

And then you refactor the final printf() into the call to the new fun-
ction.

This is much shorter, and clearer.  I hope you weren't talking about the
/inline/ keyword.  It also has the side effect of not needing the
/break/ keyword at all.


Best wishes, and happy short switch () statements!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402714

On 10/6/2026 5:22 AM, Johann 'Myrkraverk' Oskarsson wrote:
> On 10/5/2026 8:46 AM, bart wrote:
>> On 05/10/2026 00:44, Lawrence D’Oliveiro wrote:
>>> On Sun, 4 Oct 2026 09:05:06 -0700, Andrey Tarasevich wrote:
>>>
>>>> I usually employ a much better method, which should really be
>>>> included into every coding standard: just interlace your switch
>>>> statement with a dummy if-else ladder.
>>>
>>> The more code you have to write, the more opportunities there are to
>>> get things wrong. And maintenance takes more work, too.
>>>
>>
>> I don't know if AT was being serious. This was the proposal:
>>
>>    for (unsigned n = 100; n > 0; --n)
>>      {
>>        switch (rand() % 4)
>>        {
>>          if (0) {
>>          case 0:
>>            printf("Case zero");
>>          } else  if (0) {
>>          case 1:
>>            printf("Case one");
>>          } else  if (0) {
>>          case 2:
>>            printf("Case two");
>>          } else  if (0) {
>>          case 3:
>>            printf("Case three");
>>          }
>>          printf("\n");
>>        }
>>      }
>>    }
>>
>>
>> It looks more of a mess than just writing the breaks. And there is 
>> something funny about it: that final 'printf' is inside the switch's 
>> compound statement, and here it is executed after any of the 4 cases.
>>
>> Without the if-ladder, it would have to go outside the compound 
>> statement. So it changes the behaviour subtly.
>>
>> Here is the same functionality as above, using my everyday language:
>>
>>      to 100 do
>>          switch rand() rem 4
>>          when 0 then print "Case zero"
>>          when 1 then print "Case one"
>>          when 2 then print "Case two"
>>          when 3 then print "Case three"
>>          end
>>          println
>>      end
>>
>> There is little clutter and little ambiguity. This is why syntax is 
>> important including doing 'switch' properly.
>>
>>
>> For a fairer comparison, here is more idiomatic C:
>>
>>    for (unsigned n = 100; n > 0; --n)
>>      {
>>        switch (rand() % 4) {
>>          case 0:
>>            printf("Case zero");
>>            break;
>>          case 1:
>>            printf("Case one");
>>            break;
>>          case 2:
>>            printf("Case two");
>>            break;
>>          case 3:
>>            printf("Case three");
>>            break;
>>        }
>>        printf("\n");
>>      }
>>
>> Needing those breaks makes it harder to inline the cases and printfs.
> 
> Oh, it's not hard at all.  What you do to put everything in a single
> line, is to wrap the whole thing an a function, then you can just return
> the value of the printf(), and no error code is lost.
> 
>    for ( signed n = 100 ; n > 0 ; n-- ) switch ( n ) {
>      /* Gets rid of the superfluous curlies before the switch.  */
>      case 0: return printf( "case zero" ) ;
>      case 1: return printf( "case one" ) ;
>      case 2: return printf( "case two" ) ;
>      case 3: return printf( "case three" ) ;
>    }
> 
> And then you refactor the final printf() into the call to the new fun-
> ction.
> 
> This is much shorter, and clearer.  I hope you weren't talking about the
> /inline/ keyword.  It also has the side effect of not needing the
> /break/ keyword at all.
> 
> 
> Best wishes, and happy short switch () statements!

Dear me!  I forgot to put the rand() in the switch, so here goes.

     for ( signed n = 100 ; n > 0 ; n-- ) switch ( rand( n ) % 4 ) {

Much better, and we are now approaching the line length limit of Usenet.
This makes much better use of the vertical space, and saves pages for
the inevitable printout.


Best wishes, and happy C coding!
-- 
Johann | email: invalid -> com | http://www.myrkraverk.com/blog/
I'm not from the Internet, I just work there. | via Easynews.com
https://bsky.app/profile/myrkraverk.bsky.social | for ( ;; ) _:;
Federated at https://fed.brid.gy/bsky/myrkraverk.bsky.social

[toc] | [prev] | [next] | [standalone]

#402866

For comparison, here is an example of Python’s match-statement. Like
all the good (i.e. non-C-based) designs, the designers saw no point in
having fall-through.

This is a very simple example, involving straight matching of values
against instances of an enum. There are also more complex
pattern-matching options available.

    for b in sb :
        self.chars_seen.append(b)
        match self.parse_state :
            case PARSE_STATE.EXPECT_LEN :
                if ord("0") <= b <= ord("9") :
                    digit = b - ord("0")
                    if digit == 0 and len(self.chars_seen) == 2 and self.len == 0 :
                        raise NetstringSyntaxError \
                          (
                                "length must not have leading zero: %s"
                            %
                                bytes(self.chars_seen).decode()
                          )
                    #end if
                    if (
                            self.len > MAX_NETSTRING_LEN // 10
                        or
                                self.len == MAX_NETSTRING_LEN // 10
                            and
                                digit > MAX_NETSTRING_LEN % 10
                    ) :
                        raise NetstringSyntaxError \
                            ("length too large: %s" % bytes(self.chars_seen).decode())
                    #end if
                    self.len = self.len * 10 + digit
                elif b == ord(":") :
                    if len(self.chars_seen) < 2 :
                        raise NetstringSyntaxError \
                            ("missing length prefix: %s" % repr(bytes(self.chars_seen)))
                    #end if
                    if self.len != 0 :
                        self.parse_state = PARSE_STATE.EXPECT_CHARS
                    else :
                        self.parse_state = PARSE_STATE.EXPECT_END
                    #end if
                    self.content = []
                else :
                    raise NetstringSyntaxError \
                      (
                            "expecting digits of length or colon: %s"
                        %
                            repr(bytes(self.chars_seen))
                      )
                #end if
            #end case
            case PARSE_STATE.EXPECT_CHARS :
                self.content.append(b)
                self.len -= 1
                if self.len == 0 :
                    self.parse_state = PARSE_STATE.EXPECT_END
                #end if
            #end case
            case PARSE_STATE.EXPECT_END :
                if b == ord(",") :
                    self.parse_state = PARSE_STATE.PARSE_DONE
                else :
                    raise NetstringSyntaxError \
                        ("expecting comma after netstring: %s" % repr(bytes(self.chars_seen)))
                #end if
            #end case
            case PARSE_STATE.PARSE_DONE :
                raise NetstringSyntaxError \
                    ("junk after complete netstring: %s" % repr(bytes(self.chars_seen)))
            #end case
        #end match
    #end for

[toc] | [prev] | [next] | [standalone]

#402867

On 10/10/2026 01:25, Lawrence D’Oliveiro wrote:
> For comparison, here is an example of Python’s match-statement. Like
> all the good (i.e. non-C-based) designs, the designers saw no point in
> having fall-through.

C, doesn't specifically have fallthrough. It's just that C's switch is 
so bizarre, 'fallthrough' is a consequence of it being so dumb it 
doesn't know it's still inside a switch statement; it is just code that 
it carries ploughing through until it hits more control flow.


> This is a very simple example, involving straight matching of values
> against instances of an enum. There are also more complex
> pattern-matching options available.
> 
>      for b in sb :
>          self.chars_seen.append(b)
>          match self.parse_state :

I think Python 'match' is just linear testing (I didn't notice any 
speed-ups when I tried it).

Real 'switch' allows for a jump-table and O(1) parallel matching against 
N unique possibilities.

>              case PARSE_STATE.EXPECT_LEN :

A jump-table would need all these expressions to be known at 
compile-time, and to be immutable. (This is why Python can't have nice 
things.)

>                  if ord("0") <= b <= ord("9") :

Why not:

     if b in digits:              # digits is range(ord("0"), ord("9")+1)

[toc] | [prev] | [next] | [standalone]

#402868

bart <bc@freeuk.com> writes:
> On 10/10/2026 01:25, Lawrence D’Oliveiro wrote:
>> For comparison, here is an example of Python’s match-statement. Like
>> all the good (i.e. non-C-based) designs, the designers saw no point in
>> having fall-through.
>
> C, doesn't specifically have fallthrough. It's just that C's switch is
> so bizarre, 'fallthrough' is a consequence of it being so dumb it
> doesn't know it's still inside a switch statement; it is just code
> that it carries ploughing through until it hits more control flow.

C's switch statement is essentially a computed goto.  It goes back
to BCPL (1967), which had different syntax (SWITCHON, CASE, ENDCASE)
but similar semantics.  BCPL's predecessor, CPL, had a more explicit
computed goto that could be used in the same way; the target of a
"go to" could be a label expression.

Think of C's "switch", not as an inferior version of Pascal's case
statement, but as an improved version of a computed goto.

The ANSI C Rationale says "No serious consideration was given to
making the switch more structured, as in Pascal, out of fear of
invalidating working code".

I suppose some version of C could have defined a new switch-like
statement without the fallthrough behavior.  I can see some small
advantages in doing so, but the existing switch with fallthrough
would have to be kept in the language -- and such a new switch-like
statement would have added no real expressive power.  We'd now have
a mix of code using the old and new constructs, pressure to convert
existing working code, and probably errors introduced by converting
code incorrectly.

Anything you could do with a more structured switch-like statement can
be done, with just a little care, with the existing switch statement.

Yes, you have to remember to write "break;" at the end of each case.

I haven't seen any proposals to add such a feature -- probably
because nobody else is as angry about it as you are.

[...]

-- 
Keith Thompson (The_Other_Keith) Keith.S.Thompson+u@gmail.com
void Void(void) { Void(); } /* The recursive call of the void */

[toc] | [prev] | [next] | [standalone]

Page 5 of 10 — ← Prev page 1 … 3 4 [5] 6 7 … 10  Next page →

Back to top | Article view | comp.lang.c

csiph-web