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/