I'd disagree on the use of goto - absolute prohibitions are usually bogus as all code that could possibly be written obvious has not, and never will be, written, and cases can exist where using a goto can make the programmer's intention clearer. For sure don't use it as a general replacement for other flow control statements, but otherwise it's just another tool in your box. If you find yourself needing to write a tangled mess using regular flow control statements it's clearly a case for refactoring, and if that refactoring involves using a goto - so be it. (It's also handy for exception handling and cleanup in languages that don't have structured exceptions, like C. )

But all of this was covered in another thread some months ago.

I'd disagree on the use of goto - absolute prohibitions are usually bogus as all code that could possibly be written obvious has not, and never will be, written, and cases can exist where using a goto can make the programmer's intention clearer. For sure don't use it as a general replacement for other flow control statements, but otherwise it's just another tool in your box. If you find yourself needing to write a tangled mess using regular flow control statements it's clearly a case for refactoring, and if that refactoring involves using a goto - so be it. (It's also handy for exception handling and cleanup in languages that don't have structured exceptions, like C. )

But all of this was covered in another thread some months ago.

Let's put it this way, all of those cases ( which can be argued either way ad nauseum ), those edge cases are so far beyond the beginners forum as to not make sense even considering. Simply put, in a beginners forum , the axiom "never use goto" should simply be consider fact until the reader has the capacity to prove otherwise.

Let's put it this way, all of those cases ( which can be argued either way ad nauseum ), those edge cases are so far beyond the beginners forum as to not make sense even considering. Simply put, in a beginners forum , the axiom "never use goto" should simply be consider fact until the reader has the capacity to prove otherwise.

I disagree. If a reasonable solution calls for the use of "goto", or perhaps something similarly dangerous but less polarizing, like fall-through behavior in switch statements, then we should share it and perform our due diligence of saying "Here's a case where 'goto' might make sense because the scope is limited and because it expresses the solution clearly and directly. But don't assume 'goto' is always the answer because ..." While I agree that gotos are dangerous in abundance, I'm not particularly convinced that they are quite so evil individually -- They're kind of like zombies in that way: overwhelming in large numbers, but usually not a problem 1-on-1.

Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice. In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin". Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions

That said, more structured solutions are preferable when they are equally clear in their intent, I'm just not convinced that nesting a 'for' loop or two inside of a 'while' loop is more clear in its intention than "goto LOOP_RESTART;" I've had little use for 'goto' myself in C, and less so in C++, but I have had use for it, on occasion.


To the OP: If you want to restart the loop, retaining the current counter value, that is what the 'continue' keyword is for -- don't feel dumb for missing this, 'continue' is not very well known to most beginning programmers, or even intermediate ones. If you want to restart the loop entirely, with a fresh counter, then using 'goto' is one legitimate option. Another is to use a 'break;' statement in the same location you would place your 'goto' and wrapping the for loop in another loop. Which is best is a matter of situation and preference, but both are valid solutions. In any case, be mindful of any other state accessed in the for loop which might need to be re-initialized.

Also, if you have the misfortune of using Visual C++ 6, I'm terribly, terribly sorry. Anyhow, VC++6 is broken, and doesn't respect the scope of for loop indexes like it should -- that is, the scope is not limited to the for loop itself, but to the enclosing scope -- if you break out, or goto a line before the for loop, the value of the variable will likely remain the same as it was when you got out of the loop, and it will need to be reset. Better still, upgrade your compiler to any number of better, completely free (as in beer and/or speech) compilers, including Microsoft's latest Express editions.

Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.

I think a more apt analogy would be if that hammer was a occasionally useful hammer, but it had a tendency to give the users slivers. Since there are an abundance of perfectly usable hammers, that particular hammer gets put away.

In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin".
[/quote]

This happens all the time in education. Early history classes don't go into the story of Auschwitz or other catastrophic events in history until the student is mature enough to handle it. Selective education is a very establish and reasonable policy.

Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions
[/quote]

Goto is much like the Singleton pattern, an easy crutch early in development, that has a whole lot of downsides that the student is currently incapable of understanding. Like the Singleton, there are *some* cases where it might be a valid construct, but they are a ways down the road.


For someone just getting started with programming, there are already so many things to learn you have to be careful not to overwhelm them. When it comes to streamlining what concepts to introduce and not to introduce, goto should be one of the first items on the chopping block.

[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.

I'd attribute it more to the more specialized types of saws and cutters, which most people, even skilled people, are allowed to do until they've used the more basic/common tools because too many people cut their fingers off.

There's no need to give beginners every tool when they can use the tools they have. Over time as finding the best tool for the job becomes important then show them the right tool. I certainly wouldn't advise someone who doesn't know how to creatively use loops to start using gotos.
[/quote]

Damn it, your analogy is better than mine.

[font="arial, verdana, tahoma, sans-serif"]

[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.

I'd attribute it more to the more specialized types of saws and cutters, which most people, even skilled people, aren't allowed to do until they've used the more basic/common tools because too many people cut their fingers off.

There's no need to give beginners every tool when they can use the tools they have. Over time as finding the best tool for the job becomes important then show them the right tool. I certainly wouldn't advise someone who doesn't know how to creatively use loops to start using gotos.[/font]
[font="arial, verdana, tahoma, sans-serif"][/quote][/font]
[font="arial, verdana, tahoma, sans-serif"] [/font][font="arial, verdana, tahoma, sans-serif"]
But that's not what's happening here, most of all because fingers don't grow back, but crappy code can be fixed up good as new with a little effort, if and when it proves to be a problem. That's not carte blanch to write shitty code just for kicks and laziness, I'm just pointing out that sometimes a single goto is the elegant solution, as opposed to erecting some otherwise useless super-structure, and we shouldn't pretend that that isn't the case because we don't think a beginner can handle the truth. Besides, lets not pretend that someone who would be naive enough to abuse goto is writing mission-critical software. Most likely that code will be buried in some text-based tic-tac-toe program that will never leave the comfort of their hard-disk, and then disappear in a disk-crash because it wasn't worth backing up.[/font]
[font="arial, verdana, tahoma, sans-serif"] [/font]
[font="arial, verdana, tahoma, sans-serif"]Also, what's essentially been advocated above by many, is to make the solution more complicated than it needs to be, in order to feel good about the way it got solved. That's almost always terrible advice (note that this is not the same thing as "do the simplest thing, regardless of where the code is heading."). That's precisely the line of reasoning that makes Singleton attractive -- It's global state that *feels" all happy and object-oriented -- a wolf in sheep's clothing.[/font]

[quote name='Ravyne' timestamp='1320275860' post='4879922']
Basically, what I don't agree with is deciding to hide all the hammers just because some shop-class flunkies are bound to smash their fingers once or twice.

I think a more apt analogy would be if that hammer was a occasionally useful hammer, but it had a tendency to give the users slivers. Since there are an abundance of perfectly usable hammers, that particular hammer gets put away.
[/quote]

Fine, but we don't pretend that this thorny hammer doesn't exist -- we say "Go get the Thorny Hammer, but put on some freaking gloves, will you!" -- If we leave out the part about wearing gloves, then it is we who have failed, rather than the dude swinging the thing.

In other arenas, when you deny that things exist for no reason other than "its in your best interest", we would call that censorship, or at the very least, "spin".
[/quote]

This happens all the time in education. Early history classes don't go into the story of Auschwitz or other catastrophic events in history until the student is mature enough to handle it. Selective education is a very establish and reasonable policy.
[/quote]

But it cuts both ways -- sometimes you have to introduce a topic ahead of where it can be fully explained in order to progress -- and in that case you tell the receiver of the information what they need to know, with due caution and without premature bias.

Take for example the mathematical identities: (-1)^(2n) = 1 and (-1)^(2n - 1) = -1 [where n is an integer]

These identities (particularly replacing -1 for any negative integer, and the result with a positive and negative unknown, respectively) is common in high-school level algebra and calculus, but a mathematical proof of this concept is well beyond a high-school classroom -- yet, students must know this identity in order to be presented with many interesting problems.

As much as I am for knowing how things work internally, its not always practical to simply say "You cannot prove it is, so therefore you cannot use it" -- indeed, sometimes this is antithetical to progress.

Neither has a place in academics. Its more than fine to debate the value of goto, or to advocate fervently against it, but its another thing entirely to deny it to an entire class of people because of their perceived limitations. Have more faith in your fellow man, or at least uphold his innate right to make stupid, uninformed decisions
[/quote]

Goto is much like the Singleton pattern, an easy crutch early in development, that has a whole lot of downsides that the student is currently incapable of understanding. Like the Singleton, there are *some* cases where it might be a valid construct, but they are a ways down the road.[/quote]

Singleton is very different and much more insidious -- just *one* Singleton make predicting program state impossible (at least at the level of mathematical proof) and has global reach by definition. Goto can, and should, be limited in scope -- to a single, local scope in 99 cases out of 100; neither should a goto break down in the face of multi-threaded programming in the way that naive singleton implementations do. Singleton is essentially *never* a necessary construct unless there are devices or assumptions it represents that exist in the physical world -- eg, a resource in an integrated circuit that is by definition (rather than convenience) singular.

I'm certainly not advocating that goto is a good thing, or that one should jump across function or module boundaries with one -- I'm merely saying that in a certain set of circumstances, with limited scope, and clear intentions, a goto can be a good solution -- and that to pretend otherwise, no matter how badly it falls apart at large scale, is intellectually dishonest and unpragmatic, particularly when alternative solutions are needlessly complicated.

For someone just getting started with programming, there are already so many things to learn you have to be careful not to overwhelm them. When it comes to streamlining what concepts to introduce and not to introduce, goto should be one of the first items on the chopping block.
[/quote]

I agree with the premise, but not the conclusion. The way to not overwhelm someone is not to tear out parts of the map, but to mark the dangerous parts of the world with a big red X, and where a clear and pragmatic set of rules exist for negotiating this dangerous territory, to share them.

Back in the day, when many newbie programmers cut their teeth on assembly language, all they had were essentially gotos -- yet, no one said "Dear God! Run! That JMP statement is about to bite!" people understood the purpose and ramifications of the various jump statements. Perhaps it can be said that structured languages make it easy, or even attractive to jump willy-nilly through great expanses of a program, but the mechanism itself is no more or less dangerous than it was back then. Indeed, if structural programming, where it has not *completely* alleviated the need for goto, does indeed serve to obfuscate the potential negative consequences of using it, then our reaction should not be to place it behind glass and chide new programmers never to touch it, but to re-double our efforts to explain *why* it mostly sits high on a shelf, behind glass these days -- After all, the tool which is most dangerous to you is the one you know nothing about.

I'd actually say that goto is much cleaner and less prone to WTFery than some creative uses of loops you sometimes find: witness Duff's Device (although goto is not a replacement there, but it is an example of a creative loop) or the do [...} while (0) pattern. A certain school of argument is that break and continue are nothing more than specialized forms of goto anyway. It's certainly no harm having beginners be at least aware that goto does exist, and aware of the reasons why it should not be your first choice, otherwise the risk is that they'll discover it on their own elsewhere. For that last reason alone I think that suppressing the information does more harm than good, despite best intentions.

So my analogy is that goto is like sex education. They're going to find out anyway, and if they find out from the wrong sources they're going to end up with a jumble of confusing and incorrect information and may end up trying out things that they really shouldn't. Better they find out the right way. ;)

So my analogy is that goto is like sex education. They're going to find out anyway, and if they find out from the wrong sources they're going to end up with a jumble of confusing and incorrect information and may end up trying out things that they really shouldn't. Better they find out the right way. ;)

Good sir, you win the Golden Analogy Award. Congratulations!