3 ms·

One nice thing about a classic jump table is that you can change the function pointers dynamically. That might seem like a questionable thing to do, but it's p

One nice thing about a classic jump table is that you can change the function pointers dynamically. That might seem like a questionable thing to do, but it's pretty handy to intercept or wrap functions. Calling different functions depending on state/context can be more efficient than calling one function that has to check that same state/context on every single call, and it's slightly easier to set breakpoints that way too. Forget about doing any of that with the switch-statement or threaded versions. Unless you're writing something that has to run billions of times per second, like an interpreter's inner loop, the extra flexibility is worth it.

terminalcommand 9y ago
On my first attempt of writing an IRC parser by following a specification at an RFC, I wrote the whole tokenizer in a single switch statement. But as I needed further branches I resorted to using nested switch statements. It quickly became a mess. Then I switched to calling seperate functions within the switch statement for tokens. If the char is a colon and state is prefix, call parsePrefix. If the char is a whitespace, advance state etc. I didn't know about jump tables back then, but relying on enums for states and branching proved to be a good idea. e.g If state is < 3, parseParameters(); if state is <2, parseMessage() etc. Using nested conditionals and loops in the same function on the other hand proved to be a terrible idea.