Messages in this thread | | | Date | Thu, 21 Jan 1999 13:14:41 +0000 | From | Jamie Lokier <> | Subject | Re: Structure vs purism ? |
| |
> The use of constructs such as goto are outdated crutches used by > people too lazy to write a more structured solution.
1. Structured solutions tend to nest more deeply (which Linus doesn't like) or have lots of function calls (which he does like, if they're sensible).
2. To reduce nesting, there is a tendancy to put the special cases in the form `if (unlikely_condition) { special_case_code; }', which is the opposite of optimal from a speed perspective; see #3. There was a brief initiative to teach GCC when it should rearrange the code to the faster form, by using special assertions.
2. It can be argued that for handling error conditions, the `goto out', `goto out_and_free' etc. is cleaner, clearer and more structured. It certainly leads to smaller source code (no duplication of the recovery path). And it means the essential work of the function doesn't have to be nested to some silly depth. (`if (ok1) { ...; if (ok_2) { ...; if (ok_3) { ...; if (ok_4) { ...; } } } }').
And some silly speed arguments:
3. Many of the more "hard core" functions use gotos because that orders the code to put the likely cases earlier, which runs faster on modern processors as well as old ones.
4. Modern branch prediction statically predicts unconditional jumps correctly all the time. (i.e. `goto' _not_ preceded by `if').
In short, the "gotos are evil" arguments are not universally convincing.
There is a paper somewhere analysing code with and without gotos, showing that the code _without_ the gotos is sometimes much more complicated, to handle all the exceptional cases. Sorry I don't have the URL.
However, where you have changed code so that is clearer (= smaller, usually), and it's not time critical code (or your changes improve the timing), I'm sure it will be of interest.
-- Jamie
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |