Yes, I've read "just a wee bit" :^) of Edsger Dijkstra, over the years, and he's more-or-less always been on the mark; but something tells me you've never written a state machine running on "bare metal" in hard, real time.
There are a few (if very few) legitimate uses for GOTO--mostly for exception handling--outside of embedded work. Some types of state machines qualify; but most, thankfully, reduce to a case structure, wrapped in a loop.
In the embedded world, it gets a little different: sometimes there's no other way to squeeze out the few (or even few hundred) bytes needed to fit into your microcontroller's ROM, without going to a much larger, and significantly more expensive part. (If $0.007 per unit makes a big difference across 1,000,000 units, imagine what a difference of $3.60 does.) The same may apply if you're running low on RAM (which in microcontrollers, may be 256 bytes or far less [I've worked with one 4-bitter that had only 64 *digits* {nybbles} of RAM])--not all applications have the luxury of "plenty of memory".
I remember a chassis-bus message handler, in an automotive HVAC control, that required jumps from the end of every branch of a massive case structure, to one of a handful of "common tail" sequences, in order to fit into the available ROM and execution time (it was in an interrupt handler). Jumping directly to each tail section saved some 300 bytes. Since this was written in assembler (where a GOTO looks no different from a "structured" language construct), this wasn't a big deal, anyway. Had it been written in 'C', for example, it would still have required 'goto': the sheer number of cases and the multiple tail sections would have foiled any optimizer I have yet seen.
Remember, this is a case where we had to cram everything into a 16kB ROM, or go to much more expensive 32kB part, when we were going to make *millions* of units...the annual cost of going to the larger part would have exceeded the salary of the entire development team!
Fortunately, outside of embedded development, clarity and ease of maintenance can usually take priority over raw efficiency of the implementation. For example, I'd never write a compiler "by hand", given the possibility of using 'lex' and 'yacc'.
--
HadEnuf?
|
