GOTO still considered harmful?

The following statements are generalizations; while it is always possible to plead exception, it usually (in my experience and humble opinion) isn't worth the risks. Unconstrained use of memory addresses (either GOTO or raw pointers) provides too many opportunities to make easily avoidable mistakes. The more ways there are to arrive at a particular "location" in the code, the less confident one can be about what the state of the system is at that point.(See below.

) Structured programming IMHO is less about "avoiding GOTOs" and more about making the structure of the code match the structure of the data. For example, a repeating data structure (e.g. Array, sequential file, etc. ) is naturally processed by a repeated unit of code. Having built-in structures (e.g. While, for, until, for-each, etc. ) allows the programmer to avoid the tedium of repeating the same cliched code patterns.

Even if GOTO is low-level implementation detail (not always the case!) it's below the level that the programmer should be thinking. How many programmers balance their personal checkbooks in raw binary? How many programmers worry about which sector on the disk contains a particular record, instead of just providing a key to a database engine (and how many ways could things go wrong if we really wrote all of our programs in terms of physical disk sectors?

Footnotes to the above: Re point 2, consider the following code: a = be + 1 /* do something with a */ At the "do something" point in the code, we can state with high confidence that a is greater than b. (Yes, I'm ignoring the possibility of untrapped integer overflow. Let's not bog down a simple example.) On the other hand, if the code had read this way: ... goto 10 ... a = be + 1 10: /* do something with a */ ... goto 10 ... The multiplicity of ways to get to label 10 means that we have to work much harder to be confident about the relationships between a and be at that point.

(In fact, in the general case it's undecideable! ) Re point 4, the whole notion of "going someplace" in the code is just a metaphor. Nothing is really "going" anywhere inside the CPU except electrons and photons (for the waste heat).

Sometimes we give up a metaphor for another, more useful, one. I recall encountering (a few decades ago!) a language where if (some condition) { action-1 } else { action-2 } was implemented on a virtual machine by compiling action-1 and action-2 as out-of-line parameterless routines, then using a single two-argument VM opcode which used the boolean value of the condition to invoke one or the other. The concept was simply "choose what to invoke now" rather than "go here or go there".

Again, just a change of metaphor.

xkcd.com/292/ Since the comic is getting some hate I thought I would expand on my answer: A coworker of mine said the only reason to use a GOTO is if you programmed yourself so far into a corner that it is the only way out. In other words, proper design ahead of time and you won't need to use a GOTO later. I thought this comic illustrates that beautifully "I could restructure the program's flow, or use one little 'GOTO' instead."

A GOTO is a weak way out when you have weak design. Velociraptors prey on the weak.

5 might I suggest editing in the alt text, just xkcd completeness – shsteimer Sep 22 '08 at 23:47 22 The strip is somewhat funny. But please do not upvote jokes in a serious discussion... – EricSchaefer Nov 27 '08 at 14:39 12 Since I guess the message of the strip wasn't obvious enough, I added an answer and the strip just illustrates it. – Jim McKeeth Jan 7 '09 at 0:58 42 @EricSchaefer, I think StackOverflow, like any other forum shouldn't be devoid of humour.

– arbales Oct 24 '09 at 4:25 3 +1 for the Jurassic Park reference – Matt Fichman Oct 24 '09 at 4:32.

We already had this discussion and I stand by my point. Furthermore, I'm fed up with people describing higher-level language structures as “goto in disguise” because they clearly haven't got the point at all. For example: Even the advanced continuation control structure in Scheme can be described as a sophisticated goto.

That is complete nonsense. Every control structure can be implemented in terms of goto but this observation is utterly trivial and useless. Goto isn't considered harmful because of its positive effects but because of its negative consequences and these have been eliminated by structured programming.

Similarly, saying “GOTO is a tool, and as all tools, it can be used and abused” is completely off the mark. No modern construction worker would use a rock and claim it “is a tool. ” Rocks have been replaced by hammers.

Goto has been replaced by control structures. If the construction worker were stranded in the wild without a hammer, of course he would use a rock instead. If a programmer has to use an inferior programming language that doesn't have feature X, well, of course she may have to use goto instead.

But if she uses it anywhere else instead of the appropriate language feature she clearly hasn't understood the language properly and uses it wrongly. It's really as simple as that.

25 Of course, the proper use of a rock isn't as a hammer. One of its proper uses is a grinding stone, or for sharpening other tools. Even the lowly rock, when used properly is a good tool.

You just have to find the proper usage. Same goes for goto. – Kibbee Nov 27 '08 at 14:00 3 So what is the proper use of Goto?

For every case imaginable there's another tool better suited. And even your grinding stone is actually replaced by high-tech tools nowadays, even if they are still made of rock. There's a big difference between a raw material and a tool.

– Konrad Rudolph Nov 27 '08 at 17:56 4 @jalf: Goto most certainly does exist in C#. See stackoverflow.com/questions/359436/… – Jon Skeet Dec 11 '08 at 15:30 4 As a note I have used rocks as sharpening stones. Works great when you need to sharpen a knife and didn't pack a stone.

There are times and places for every tool. There even times you might use a rock to drive something into the ground (say setting up a tent and you don't feel like lugging a hammer around. ) Never say never... Also there are times when using the latest tool is not the right choice either.

I have seen people take 20 minutes to setup a powersaw to cut something that would of taken less than a minute to do with a hand saw. – Matthew Whited Dec 9 '09 at 18:13 9 I am dismayed so many people approve of this post. Your post only seemed effective because you never bothered to question what logic you were actually performing, thus you failed to notice your fallacy.

Allow me to paraphrase your entire post: "There is a superior tool for a goto in every situation, so gotos should never be used. " This is a logical biconditional, and as such your entire post is essentially begging the question "How do you know there is a superior tool for a goto in every situation? " – Coding With Style Feb 3 '10 at 22:00.

Sometimes it is valid to use GOTO as an alternative to exception handling within a single function: if (f() == false) goto err_cleanup; if (g() == false) goto err_cleanup; if (h() == false) goto err_cleanup; return; err_cleanup: ... COM code seems to fall into this pattern fairly often.

7 I agree, there are legitimate use cases where, goto can simplify code and make it more readable/maintainable, but there seems to be some sort of goto-phobia floating around ... – Pop Catalin Nov 28 '08 at 4:00 17 @Bob: It's hard to move the err_cleanup code into a subroutine if it's cleaning up local variables. – Niki Apr 12 '09 at 8:00 2 Actually, I used it in COM/VB6 just because I had no alternative, not because it was an alternative. How happy I am nowadays with try / catch / finally.

– Rui Craveiro Jun 9 '09 at 11:01.

Goto is extremely low on my list of things to include in a program just for the sake of it. That doesn't mean it's unacceptable. Goto can be nice for state machines.

A switch statement in a loop is (in order of typical importance): (a) not actually representative of the control flow, (b) ugly, (c) potentially inefficient depending on language and compiler. So you end up writing one function per state, and doing things like "return NEXT_STATE;" which even look like goto. Granted, it is difficult to code state machines in a way which make them easy to understand.

However, none of that difficulty is to do with using goto, and none of it can be reduced by using alternative control structures. Unless your language has a 'state machine' construct. Mine doesn't.

On those rare occasions when your algorithm really is most comprehensible in terms of a path through a sequence of nodes (states) connected by a limited set of permissible transitions (gotos), rather than by any more specific control flow (loops, conditionals, whatnot), then that should be explicit in the code. And you ought to draw a pretty diagram. Setjmp/longjmp can be nice for implementing exceptions or exception-like behaviour.

While not universally praised, exceptions are generally considered a "valid" control structure. Setjmp/longjmp are 'more dangerous' than goto in the sense that they're harder to use correctly, never mind comprehensibly. There never has been, nor will there ever be, any language in which it is the least bit difficult to write bad code.

-- Donald Knuth. Taking goto out of C would not make it any easier to write good code in C. In fact, it would rather miss the point that C is supposed to be capable of acting as a glorified assembler language.

Next it'll be "pointers considered harmful", then "duck typing considered harmful". Then who will be left to defend you when they come to take away your unsafe programming construct? Eh?

2 Personaly, this is the comment I would have given the check to. One thing I'd like to point out to readers is that the esoteric term "state machines" includes such everyday things as lexical analysers. Check out the output of lex somtime.

Full of gotos. – T.E.D. Dec 10 '08 at 18:39 2 +1 Those arrows on state machines map to 'goto' more closely than to any other control structure. Sure, you can use a switch inside a loop -- just like you can use a bunch of gotos instead of a while for other problems, but it's usually a idea; which is the whole point of this discussion.

– Edmund Apr 6 '09 at 23:35.

I can only recall using a goto once. I had a series of five nested counted loops and I needed to be able to break out of the entire structure from the inside early based on certain conditions: for{ for{ for{ for{ for{ if(stuff){ GOTO ENDOFLOOPS; } } } } } } ENDOFLOOPS: I could just have easily declared a boolean break variable and used it as part of the conditional for each loop, but in this instance I decided a GOTO was just as practical and just as readable. No velociraptors attacked me.

23 "No velociraptors attacked me. " - haha – Brian R. Bondy Sep 17 '08 at 13:51 20 Refactor it into a function and replace goto with return :) – leppie Sep 23 '08 at 18:33 20 "Refactor it into a function and replace goto with return :)", and the difference is?

Really what's the difference? Isn't return a go to also? Returns also brakes the structured flow of like goto does, and in this case they do it the same way (even if goto can be used for meaner things) – Pop Catalin Nov 28 '08 at 4:04 8 Nesting lots of loops is usually a code smell all it's own.

Unless you are doing, like, 5-dimensional array multiplication, it's hard to picture a situation where some of the inner loops couldn't be usefully extracted into smaller functions. Like all rules of thumb, there are a handful of exceptions I suppose. – Doug McClean Jul 17 '09 at 5:29 4 Replacing it with a return only works if you are using a language that supports returns.

– Loren Pechtel Oct 24 '09 at 3:31.

In Linux: Using goto In Kernel Code on Kernel Trap, there's a discussion with Linus Torvalds and a "new guy" about the using of GOTOs in linux code. Some very good points there and Linus dressed in that usual arrogance :) Some passages: Linus: "No, you've been brainwashed by CS people who thought that Niklaus Wirth actually knew what he was talking about. He didn't.

He doesn't have a frigging clue. " - Linus: "I think goto's are fine, and they are often more readable than large amounts of indentation. " - Linus: "Of course, in stupid languages like Pascal, where labels cannot be descriptive, goto's can be bad."

Cheers.

They are discussing its use in a language which has nothing else. When you're programming in assembly, all branches and jumps are goto's. And C is, and was, a "portable assembly language".

Moreover, the passages you quote say nothing about why he thinks goto is good. – jalf Dec 10 '08 at 18:37 3 Wow. That's disappointing to read.

You'd think a big OS guy like Linus Torvalds would know better than to say that. Pascal (old-school pascal, not the modern Object version) was what Mac OS Classic was written in during the 68k period, and it was the most advanced operating system of its time. – Mason Wheeler Dec 15 '08 at 22:51 1 rummages through the link I guess if you are coding in C, GOTO is more useful.

But if you're in a modern language which supports exceptions... – Paul Nathan Jan 14 '09 at 16:44 3 -1 Linus Torvalds – MarkJ Mar 28 '09 at 21:22 6 Linus only argues (explicitly, like Rik van Riel in that discussion) for goto for handling exit status, and he does so on the basis of the complexity that C's alternative constructs would bring if they were used instead. – Charles Stewart Jan 12 '10 at 13:40.

In C, goto only works within the scope of the current function, which tends to localise any potential bugs. Setjmp and longjmp are far more dangerous, being non-local, complicated and implementation-dependent. In practice however, they're too obscure and uncommon to cause many problems.

I believe that the danger of goto in C is greatly exaggerated. Remember that the original goto arguments took place back in the days of languages like old-fashioned BASIC, where beginners would write spaghetti code like this: 3420 IF A > 2 THEN GOTO 1430.

4 When BASIC was first available, there wasn't any alternative to GOTO nnnn and GOSUB mmmm as ways to jump around. Structured constructs were added later. – Jonathan Leffler Oct 24 '09 at 6:13 3 You're missing the point... even then you didn't have to write spaghetti... your GOTOs could always be used in a disciplined manner – JoelFan Jan 11 '10 at 19:01.

Donald E. Knuth answered this question in the book "Literate Programming", 1992 CSLI. On p.17 there is an essay "Structured Programming with goto Statements" (PDF).

I think the article might have been published in other books as well. The article describes Dijkstra's suggestion and describes the circumstances where this is valid. But he also gives a number of counter examples (problems and algorithms) which cannot be easily reproduced using structured loops only.

The article contains a complete description of the problem, the history, examples and counter examples.

Attracted by Jay Ballou adding an answer, I'll add my £0.02. If Bruno Ranschaert had not already done so, I'd have mentioned Knuth's "Structured Programming with GOTO Statements" article. One thing that I've not seen discussed is the sort of code that, while not exactly common, was taught in Fortran text books.

Things like the extended range of a DO loop and open-coded subroutines (remember, this would be Fortran II, or Fortran IV, or Fortran 66 - not Fortran 77 or 90). There's at least a chance that the syntactic details are inexact, but the concepts should be accurate enough. The snippets in each case are inside a single function.

Note that the excellent but dated (and out of print) book 'The Elements of Programming Style, 2nd Edn' by Kernighan & Plauger includes some real-life examples of abuse of GOTO from programming text books of its era (late-70s). The material below is not from that book, however. Extended range for a DO loop do 10 I = 1,30 ...blah... ...blah... if (k.gt.4) goto 37 91 ...blah... ...blah... 10 continue ...blah... return 37 ...some computation... goto 91 One reason for such nonsense was the good old-fashioned punch-card.

You might notice that the labels (nicely out of sequence because that was canonical style! ) are in column 1 (actually, they had to be in columns 1-5) and the code is in columns 7-72 (column 6 was the continuation marker column). Columns 73-80 would be given a sequence number, and there were machines that would sort punch card decks into sequence number order.

If you had your program on sequenced cards and needed to add a few cards (lines) into the middle of a loop, you'd have to repunch everything after those extra lines. However, if you replaced one card with the GOTO stuff, you could avoid resequencing all the cards - you just tucked the new cards at the end of the routine with new sequence numbers. Consider it to be the first attempt at 'green computing' - a saving of punch cards (or, more specifically, a saving of retyping labour - and a saving of consequential rekeying errors).

Oh, you might also note that I'm cheating and not shouting - Fortran IV was written in all upper-case normally. Open-coded subroutine ...blah... I = 1 goto 76 123 ...blah... ...blah... I = 2 goto 76 79 ...blah... ...blah... goto 54 ...blah... 12 continue return 76 ...calculate something... ...blah... goto (123, 79) I 54 ...more calculation... goto 12 The GOTO between labels 76 and 54 is a version of computed goto. If the variable I has the value 1, goto the first label in the list (123); if it has the value 2, goto the second, and so on.

The fragment from 76 to the computed goto is the open-coded subroutine. It was a piece of code executed rather like a subroutine, but written out in the body of a function. (Fortran also had statement functions - which were embedded functions that fitted on a single line.) There were worse constructs than the computed goto - you could assign labels to variables and then use an assigned goto.

Googling assigned goto tells me it was deleted from Fortran 95. Chalk one up for the structured programming revolution which could fairly be said to have started in public with Dijkstra's "GOTO Considered Harmful" letter or article. Without some knowledge of the sorts of things that were done in Fortran (and in other languages, most of which have rightly fallen by the wayside), it is hard for us newcomers to understand the scope of the problem which Dijkstra was dealing with.

Heck, I didn't start programming until ten years after that letter was published (but I did have the misfortune to program in Fortran IV for a while).

Go To can provide a sort of stand-in for "real" exception handling in certain cases. Consider: ptr = malloc(size); if (!ptr) goto label_fail; bytes_in = read(f_in,ptr,size); if (bytes_in=But consider an alternative I've seen all too many times in production code by coders going to absurd lengths to avoid using goto: success=false; do { ptr = malloc(size); if (!ptr) break; bytes_in = read(f_in,ptr,size); if (count=However, in the programmer's zeal to appease Nogoto (the dreaded god of academic rebuke), this programmer has completely broken the underlying idiom that the while loop represents, and did a real number on the readability of the code. This is not better.

So, the moral of the story is, if you find yourself resorting to something really stupid in order to avoid using goto, then don't.

There is no such things as GOTO considered harmful. GOTO is a tool, and as all tools, it can be used and abused. There are, however, many tools in the programming world that have a tendency to be abused more than being used, and GOTO is one of them.

The WITH statement of Delphi is another. Personally I don't use either in typical code, but I've had the odd usage of both GOTO and WITH that were warranted, and an alternative solution would've contained more code. The best solution would be for the compiler to just warn you the hell out of tomorrow that the keyword was tainted, and you'd have to stuff a couple of pragma directives around the statement to get rid of the warnings.It's like telling your kids to not run with scissors.

Scissors are not bad, but some usage of them are perhaps not the best way to keep your health.

It never was, as long as you were able to think for yourself.

Since I began doing a few things in the linux kernel, gotos don't bother me so much as they once did. At first I was sort of horrified to see they (kernel guys) added gotos into my code. I've since become accustomed to the use of gotos, in some limited contexts, and will now occasionally use them myself.

Typically, it's a goto that jumps to the end of a function to do some kind of cleanup and bail out, rather than duplicating that same cleanup and bailout in several places in the function. And typically, it's not something large enough to hand off to another function -- e.g. Freeing some locally (k)malloc'ed variables is a typical case. I've written code that used setjmp/longjmp only once.

It was in a MIDI drum sequencer program. Playback happened in a separate process from all user interaction, and the playback process used shared memory with the UI process to get the limited info it needed to do the playback. When the user wanted to stop playback, the playback process just did a longjmp "back to the beginning" to start over, rather than some complicated unwinding of wherever it happened to be executing when the user wanted it to stop.

It worked great, was simple, and I never had any problems or bugs related to it in that instance. Setjmp/longjmp have their place -- but that place is one you'll not likely visit but once in a very long while. Edit: I just looked at the code.

It was actually siglongjmp() that I used, not longjmp (not that it's a big deal, but I had forgotten that siglongjmp even existed. ).

Today, it's hard to see the big deal about the GOTO statement because the "structured programming" people mostly won the debate and today's languages have sufficient control flow structures to avoid GOTO. Count the number of "goto"s in a modern C program. Now add the number of "break", "continue", and "return" statements.

Furthermore, add the number of times you use "if", "else", "while", "switch" or "case". That's about how many GOTOs your program would have had if you were writing in FORTRAN or BASIC in 1968 when Dijkstra wrote his letter. Programming languages at the time were lacking in control flow.

For example, in the original Dartmouth BASIC: IF statements had no ELSE. If you wanted one, you had to write: 100 IF NOT condition THEN GOTO 200 ...stuff to do if condition is true... 190 GOTO 300 ...stuff to do if condition is false... 300 REM end if Even if your IF statement didn't need at ELSE, it was still limited to a single line, which usually consisted of a GOTO. There was no DO...LOOP statement.

For non-FOR loops, you had to end the loop with an explicit GOTO or IF...GOTO back to the beginning. There was no SELECT CASE. You had to use ON...GOTO.So, you ended up with a lot of GOTOs in your program.

And you couldn't depend on the restriction of GOTOs to within a single subroutine (because GOSUB...RETURN was such a weak concept of subroutines), so these GOTOs could go anywhere. Obviously, this made control flow hard to follow. This is where the anti-GOTO movement came from.

If you're writing a VM in C, it turns out that using (gcc's) computed gotos like this: char run(char *pc) { void *opcodes3 = {&&op_inc, &&op_lda_direct, &&op_hlt}; #define NEXT_INSTR(stride) goto *(opcodes*(pc += stride)) NEXT_INSTR(0); op_inc: ++acc; NEXT_INSTR(1); op_lda_direct: acc = ram++pc; NEXT_INSTR(1); op_hlt: return acc; } works much faster than the conventional switch inside a loop.

The original paper should be thought of as "Unconditional GOTO Considered Harmful". It was in particular advocating a form of programming based on conditional (if) and iterative (while) constructs, rather than the test-and-jump common to early code. Goto is still useful in some languages or circumstances, where no appropriate control structure exists.

Denying the use of the GOTO statement to programmers is like telling a carpenter not to use a hammer as it Might damage the wall while he is hammering in a nail. A real programmer Knows How and When to use a GOTO. I’ve followed behind some of these so-called ‘Structured Programs’ I’ve see such Horrid code just to avoid using a GOTO, that I could shoot the programmer.

Ok, In defense of the other side, I’ve seen some real spaghetti code too and again, those programmers should be shot too. Here is just one small example of code I’ve found. YORN = '' LOOP UNTIL YORN = 'Y' OR YORN = 'N' DO CRT 'Is this correct?(Y/N) : ': INPUT YORN REPEAT IF YORN = 'N' THEN CRT 'Aborted!

' STOP END -----------------------OR---------------------- 10: CRT 'Is this Correct (Y)es/(N)o ': INPUT YORN IF YORN='N' THEN CRT 'Aborted! ' STOP ENDIF IF YORN'Y' THEN GOTO 10.

(Y/N) : ': INPUT YORN UNTIL YORN = 'Y' OR YORN = 'N'; etc. – joel. Neely Feb 14 '09 at 22:11 2 Indeed, but more importantly, a real programmer knows when not to use a goto - and knows why. Avoiding a taboo language construct because $programming_guru said so, that's the very definition of cargo-cult programming.

– Piskvor Jun 17 '10 at 8:26.

One modern GOTO usage is by the C# compiler to create state machines for enumerators defined by yield return. GOTO is something that should be used by compilers and not programmers.

– tloach Sep 23 '08 at 18:41 3 Compilers, of course! – Seiti Nov 28 '08 at 3:32 1 I think he means "GOTO is something that should only be used by code emitted by a compiler". – Simon Buchan Nov 28 '08 at 4:53.

About the only place I agree Goto could be used is when you need to deal with errors, and each particular point an error occurs requires special handling. For instance, if you're grabbing resources and using semaphores or mutexes, you have to grab them in order and you should always release them in the opposite manner. Some code requires a very odd pattern of grabbing these resources, and you can't just write an easily maintained and understood control structure to correctly handle both the grabbing and releasing of these resources to avoid deadlock.It's always possible to do it right without goto, but in this case and a few others Goto is actually the better solution primarily for readability and maintainability.

You can use it for breaking from a deeply nested loop, but most of the time your code can be refactored to be cleaner without deeply nested loops.

Until C and C++ (amongst other culprits) have labelled breaks and continues, goto will continue to have a role.

Because goto can be used for confusing metaprogramming Goto is both a high-level and a low-level control expression, and as a result it just doesn't have a appropriate design pattern suitable for most problems. It's low-level in the sense that a goto is a primitive operation that implements something higher like while or foreach or something. It's high-level in the sense that when used in certain ways it takes code that executes in a clear sequence, in an uninterrupted fashion, except for structured loops, and it changes it into pieces of logic that are, with enough gotos, a grab-bag of logic being dynamically reassembled.So, there is a prosaic and an evil side to goto.

The prosaic side is that an upward pointing goto can implement a perfectly reasonable loop and a downward-pointing goto can do a perfectly reasonable break or return. Of course, an actual while, break, or return would be a lot more readable, as the poor human wouldn't have to simulate the effect of the goto in order to get the big picture.So, a bad idea in general. The evil side involves a routine not using goto for while, break, or return, but using it for what's called spaghetti logic.

In this case the goto-happy developer is constructing pieces of code out of a maze of goto's, and the only way to understand it is to simulate it mentally as a whole, a terribly tiring task when there are many goto's. I mean, imagine the trouble of evaluating code where the else is not precisely an inverse of the if, where nested ifs might allow in some things that were rejected by the outer if, etc, etc. Finally, to really cover the subject, we should note that essentially all early languages except Algol initially made only single statements subject to their versions of if-then-else. So, the only way to do a conditional block was to goto around it using an inverse conditional.

Insane, I know, but I've read some old specs. Remember that the first computers were programmed in binary machine code so I suppose any kind of an HLL was a lifesaver; I guess they weren't too picky about exactly what HLL features they got. Having said all that I used to stick one goto into every program I wrote "just to annoy the purists".

GOTO is like a table saw, extremely useful when appropriate safety measures are taken. I consider it harmful, because most beginners lose fingers with both table saws, and GOTOs. There are some situations where its the only way to control flow, but those situations can be avoided.

I avoid it since a coworker/manager will undoubtedly question its use either in a code review or when they stumble across it. While I think it has uses (the error handling case for example) - you'll run afoul of some other developer who will have some type of problem with it. It’s not worth it.

3 Jim, the problem with that is that it's nothing more than a stupidly roundabout way of obtaining a goto. – Coding With Style Feb 6 '10 at 1:13.

On every platform I have seen, high level control structures are implemented as low level gotos (jumps). For example, the Java Virtual Machine has a Jump byte code, but nothing for if, else, while, for, etc. And some of these compilers create spaghetti code for a simple conditional block.To answer your question, goto is still considered harmful by people who believe it to be harmful. Goto makes it easy to lose the advantages of structured programming.

In the end, it's your program; and therefore your decision. I suggest not using goto until you are able to answer your question yourself, but in the context of a specific problem.

2 When you get down to the machine code, goto is the only way to get anywhere. Of course it will turn up more the closer you get. The question is is it harmful in code that is programmer-written, not compiler-generated.

– tloach Sep 23 '08 at 18:46.

In this link kerneltrap.org/node/553/2131" Ironically, eliminating the goto introduced a bug: the spinlock call was omitted.

While I think it's best to avoid goto on almost any situation, there are exceptions. For example, one place I've seen where goto statements are the elegant solution compared to others much more convoluted ways is implementing tail call elimintation for an interpreter.

Almost all situations where a goto can be used, you can do the same using other constructs. Goto is used by the compiler anyway. I personally never use it explicitly, don't ever need to.

The basic idea is that goto gives you too much freedom to do something you didn't intend to. It can cause errors in places that don't appear to be related to the goto statement, so it makes code maintenance more difficult. If you think you need a goto statement, you're wrong :) and you should instead rethink your code construction.

This is why modern programming languages have put alot of effort into giving you readable, maintainable flow control constructs, and exception handling mechanisms. I'm also going to disagree with lassevk. Since goto is abused more than correctly used, I believe it has no place in a well designed language.

Even for goto's "ideal" uses, the other ways of doing it which require more code should be preferred. So in summary, yes it is still considered harmful.

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.