B-ZaR said:
Out of curiosity, what are these cases where the use of goto is warranted, okay or even required? I've been programming for a relatively short time, about 15 years, but I've yet to come across a situation where I'd actually get any real advantage using goto instead of a loop structure or something alike. My university's department of software engineering teaches the "never goto and don't optimize, just get a better algorithm" mantra because clarity is deemed the most important aspect of code right after actually doing what it's supposed to. I know this is going really offtopic, but I'd like to hear comments on this to grow as a programmer.
One of the classic examples of using goto in C is to break out of several nested loops. This is much more concise and efficient than building bound conditions into every loop stage, yet you see people doing this just to avoid the goto. Another typical use case is breaking out to an error handler at the end of a function. This is much preferable to having several nested ifs. Again, we're talking pure C, which is still a major force in the market. goto is often effective as an optimization for quickly switching state. For instance, in an ARM interpreter I've used gotos to switch from an ARM execution loop to a Thumb execution loop on (uncommon) instructions which do so. This is far more efficient than checking the state at every iteration of the loop.
Computed gotos (GCC) can be used to implement crude/simple but effective coroutines and more efficient switch-like structures.
Your university's mantra is naive and, quite frankly, stupid. Which is not surprising, because many universities will hammer mantras like this out of a complete lack of confidence in is students to grow and eventually be capable of thinking for themselves. Which is not completely unwarranted because universities have to cater to the lowest common denominator, and especially at undergraduate level and especially at a middle of the road university a majority of the students are not going to be stellar. It's easier to teach dogma than it is to try to teach critical thinking.
That said, to an audience of experienced and, could we say, "good" programmers their advice is not useful, which is just as well because I don't think this was ever their intended audience. Choosing a better algorithm is itself an optimization, but it's insulting to the programmer's intelligence to assume that they're always using an obviously inferior algorithm. It's also overly-simplistic to think that most problems in the real programming world boil down to a matter of big O time (that's what we're talking about when we talk about "better" algorithms, right?) when the opposite is usually the case. You should choose the "best" algorithm first, which in itself will most likely contain compromise beyond some obvious decisions. Then it's suitable to target more agnostic optimizations, including but not limited to many of the things compilers will try to do (but often fail), examining said compiler output and massaging it for better results, caching and packing, improving impact on memory hierarchy, and even rolling out your own assembly.
A lot of emulators for GP2X/Wiz have achieved significant (50-100% or more) speed improvements only by utilizing well written assembly code. Unfortunately, a lot of theorists and academics won't even acknowledge such an improvement as worth consideration. So we're left with the end user's impression - is a 50% speed emulator as good as 100% speed one?