I mean, as far as I know, most would still implement this the same way.

Surely there could be a GUI framework that'll handle these Win32 Messages and dispatch them to your callbacks in your `Application` object but your application could be dealing with all sorts of messages not covered by your framework like WM_SYSCOMMAND, WM_POWERBROADCAST, WM_DEVICECHANGE, etc. and you'll find yourself with this classic Win32 Message Queue handling switch even in modern C/C++ Win32 GUI codebases.

Whenever you are interfacing with the Win32 API directly to set up and run a GUI application, this pattern will emerge: https://gist.github.com/nathan-osman/18c2e227ad00a223b61c0b3...

Found a C "goto" in that code, too - eek. Maybe there was a good reason...

There's nothing wrong with goto in C.

It's a good pattern to DRY-up resource-releasing unwind code. In an ideal world, there would be closures, RAII and fluent interfaces (macros) that would wrap allocation, deallocation, error and success handling without needing C++ and avoiding resource leaks.

    int
    some_func(void) {
      int result = ERR;

      HANDLE foo = alloc_foo();
      if (!foo) goto err0;

      HANDLE bar = alloc_bar();
      if (!bar) goto err1;

      if (do_something_else() < 0) goto err2;

      result = OK;
    err2:
      release_bar(bar);
    err1
      release_foo(foo);
    err0:
      return result;
    }

As with everything in C, it must be used with care and thought. It can come back and bite you in the future if use frivolously.

Nothing wrong with using goto, sparingly. It's the preferred way for error handling in C.

Nobody has code like this anymore

    10 I=1
    20 PRINT "HELLO "
    40 PRINT %I
    50 IF (%I > 3) 10 40
    30 PRINTLN "WORLD"
    45 PRINTLN
    42 I=%I+1

Notice no goto statement, yet lots of implicit gotos.

What about a Goto within a switch statement that's within another switch statement in a function that's 3000 lines long?