Rebuttals
C++ should/should not stuff is opinion.
Comparisons with other languages don't make valid arguments for the structure of C++. However, for languages
in general, existing need or propriety makes a pretty powerful argument.
Mr. Gosling also made emacs popular by coding and improving it in C (originally called "gosmacs") at my University: Rutgers. I believe he has since had some (minor) misgivings about his statement on gotos, but I don't care enough to dig anything up. If you care, though, you can also dig up statements by Kernighan, Wirth, Stroustrup, Torvalds and others where they indicate that there is no need to kill goto, and they have no interest in fighting over it.
(Personally, I think Gosling's original antithesis to jumping constructs has had a ruinous effect on Java's design. It is a pain to use and I'll avoid it if I can. Personally speaking.)
Goto doesn't
promote anything. Its presence does
encourage lazy programmers to be lazier, but that is not sufficient reason to attack the goto. Attack the moronic programmer.
Ada95 is a highly-structured, modern programming language.
Two valid uses of goto
Number one:
1 2 3 4 5 6 7 8 9 10 11
|
for () {
for () {
for () {
for () {
goto get_me_the_heck_out;
}
}
}
}
get_me_the_heck_out:
/* do more stuff here */
|
Anyone who argues that such as the above
can't happen is arguing that 123 Revolutionary Lane, Bosnia doesn't exist, never existed, and never will exist, just because he's never seen it. That's not the mark of an excellent programmer. Just an arrogant one, no matter how good he may generally be. Such structures actually are useful on the rare occasion.
Number two:
1 2 3 4 5 6 7
|
while ()
switch (quux) {
case fooey:
goto get_me_out_now;
}
get_me_out_now:
/* do more stuff */
|
This happens much more frequently than the last.
Arguments against the examples
The standard arguments against both of these are:
1. put some #@!?^$ boolean flags in there and test against them
2. use an exception or some other unwinding construct (it's "safer")
Flaggy code
Use of extraneous boolean variables produces what is known as "flaggy code," so-called because it is encumbered by a lot of "flag" variables (booleans and like constructs --or even worse, bitmaps) that the programmer has to wade through to see the actual structure of the code. I prefer clear reading code to extraneous constructs just to dance around using a goto.
Exceptions and other unwinding constructs
People get fanatic over
goto, but things like
switch,
break, and
continue sail right over their heads.
Functions are a form of
goto.
Exceptions (which are a special case of continuation), and things functional programmers like myself like:
continuations and
closures are yet again fancy wrappers for
gotos. In short,
everything the computer does is ultimately based on the goto, even on an electronic level.
So how do we abolish bad code if we don't abolish goto?
The purpose of higher-level constructs isn't to abolish the goto, but rather to provide a better abstraction as an end to better organized and more maintainable code, and to assist the programmer in managing closures/frames. [quoting myself again]
The mark of superior programmers isn't a blind bias against specific constructs or always/never do things "this way" rules. It is a higher level of thinking to organize not the syntactic concerns of language X, rather his
own thoughts into a lucid construct -- which is the ultimate goal and fruition of quality programming.
@
Zaita
I actually think you are a good programmer, and I enjoy posting here with you, so please don't take my comments as any attack on you at all.
I don't really care what those fellows you interviewed with think. Who do they think they are? To proclaim all truth about how to think (program) is pure hubris, and undoubtedly beyond their qualifications. To have an opinion is one thing. To deny the validity of other's opinions is another. And to stand up and make a fuss about something experts in the field consider barely worth noticing is, well, silly. (/me counts how much I've written here...)
I am not alone in my belief that to abuse structures like exceptions or otherwise introduce extra code just to avoid the use of a goto is a pretty cavalier way to spend your employer's time and money --particularly when it can be better spent thinking about the actual meaning of the code.
I write goto-free code all the time. I've used it maybe three or four times in twenty years. But when I have used it, I used it because it was the best choice for the job --producing the cleanest, most readable, maintainable, and smallest code given the alternatives. In each case I could have figured out some other convolution to avoid it, but only at the expense of code size and complexity.
So, Duoas, by your own definition you are silly, right?
Perhaps... *sheepish grin*
The reason I spend so much time on this isn't just to defend some poor, defenseless
goto out in the big, bad world.
Rather, it is so that
you, dear reader, can begin to escape being "out of the box" (which is a code-phrase for people firmly stuck deep down
inside "the box" so that they can feel good about themselves). Forget silly "always this" and "never that" and "hate this" rhetoric.
Think about what it is that your code is actually doing, and how it is organized to do it. The process is not so much programming the computer --it is programming your
own mind to understand a transformation. The more clear your own understanding, the clearer and more maintainable your own code becomes.
--Michael