[salindor]

In normal C++ coding; there is no reason to use the goto statement. Compilers are very good at optimizing code; the structural information provided by using functions, looping structures and exceptions help others know exactly why jump statements are being performed and allow a quicker learning value to come from it.

I was wondering when explaining why goto statments should be avoided; what explainations others use.

[Dogstopper]

I almost forgot goto's even existed. They aren't ever useful in the world of module programming. Generally, we use functions or the use of Object Oriented Programming instead.

As for when to use them, .... hmmmm .... I think pretty much never.

[salindor]

Dogstopper, on 14 Oct, 2009 - 09:30 PM, said:

I almost forgot goto's even existed. They aren't ever useful in the world of module programming. Generally, we use functions or the use of Object Oriented Programming instead.

As for when to use them, .... hmmmm .... I think pretty much never.

I consider what you wrote a given; just was curious if someone had a better explanation I can give besides, "I really can't stand gotos and will not accept any project which uses them"

[NickDMax]

Quote

They aren't ever useful in the world of module programming.

I would not say that was true -- you should never speak in absolutes!

Goto has its uses. For example in recent months I have seen it pop-up in a few meta-programs where I myself could not think of anyway to achieve the end result without them. They can be useful when using inline assembly routines. You will also see it in maintenance code -- This is generally sloppy and indicates that the maintenance developer did not fully understand the code had just had to hack a fix in -- but if you have have ever had to maintain code it can be understandable if not maddening and frustrating for the next guy.

So while they are hardly ever used and MOST of the time when they are the code could probably be re-written without them -- they DO get used on rare occasions.

There are several reasons to avoid them:

#1 Creating a large set of unique and useful labels sucks
#2 Goto's lead to unstructured code and it can be very difficult to figure out the logical flow of the program. -- i.e. spaghetti code, no matter where you look its all a mess of this-way and that.
#3 goto's often lead to dead code blocks.
#4 goto's are often a maintenance nightmare -- looking back on code months after it was developed it can be very very difficult to rebuild the logical structure in your mind.
#5 goto's tend to be the harbingers of tiny logic errors which form hard to spot bugs (usually because the only thing wrong with the code is transposed lines or a mislabeled goto). -- the block structure is much better.

code should "speak" -- you should be able to read it and have it tell the story of what it does. The control structures offer much more structure and meaning to code and allows it to be read. You can tell where a while-loop begins, its easy to spot the beginning and end of an if-else block -- these kinds of structures are HARD to pick out with your eye using goto's.

When I need to figure out a section of assembly language I generally turn to a debugger and hope for the best... when I have to figure out a section of code that uses goto's -- generally I end up at a debugger as well -- but I am pretty sharp at parsing structured code.

[gronk]

Gotos are useful in error handling; if you have multiple checks then you either end up nesting all those checks and reading/writing code with no end of whitespace on the left, or you invert the logic (which is confusing) and have multiple exits, which is fine if you *can* have multiple exits, or you have to invent a flag that has nothing to do with anything, set it when there's an error and keep testing it. With a goto, if a check fails you just goto the end of the function/logical section of code, or goto a block after the return that handles cleanup. But even this "need" is solved with exception handling.

[Darkhack]

Interesting discussion on the topic: http://kerneltrap.org/node/553/2131

Linus Torvalds is no amateur.

[GenHornet18]

I would have to agree with gronk, while yes the main point is that it leads to unstructured programming when used to solve errors and for a small quick fix that can be changed later a Goto is actually quite convenient. Although some of my school assignments are pretty much paperweights when there's a Goto statement in them, I still find them useful in moderation.

[hackterr]

gotos are very useful while writing code in Embedded C++
There are other(saner) ways to do the same thing but makes shifting from assembly to c++ easier as both use labels
Bottom line : NOT Recommended for code other people would be reading and changing
Spaghetti code anyone?

[polymath]

If they're used judiciously, i don't see much of a problem.

Usually i'll use them when you have a loop which might need to be exited for various reasons. Now, you could have an extra bool and set/reset/set/reset it and use continues, but sometimes i find it a whole heck of a lot easier to:

while(condition) {
   do_crap();
   if (exit_condition) {
	  //we have an error!
	  goto exit_loop;
   }
   for (blah) {
	  do_other_crap();
	  do {
		 blah;
		 if (exit_condition_2) {
			 //we have an error!
			goto exit_loop;
		 }
	  } while (yet_another_condition);
   }
   do_yet_more_crap();
   //here insert more crap...
}
exit_loop:

you can see how it can get complicated with more exit conditions, and then with more nested loops and saving exit codes it can get complicated. especially if condition happens to be ((c=a = b )-3*a)|0xFF!=e.

So, when you have nested loops and complex code, sometimes a goto can actually simplify things and allow more structure, instead of making things more complicated by having extra code just to handle the structure. Sometimes a single goto looks less like spaghetti then 50,000 if(cond)break; statements and a bunch of bools that nobody can seem to remember the meaning of...

Hey, C++ Standards Committee: Give us some sort of labeled break so we don't have to deal with all of these extraneous iffs and random break!

</schpeel>

This post has been edited by polymath: 08 November 2009 - 12:26 PM

[ccubed]

Imagine assembly code without Goto. I do believe I'd rather shoot myself than even think about it.

Seriously, Goto's do NOT create bad code, CODERS create bad code. Let's get it right. Especially when Goto is a perfectly acceptable thing in code when used RIGHT.

[KYA]

Not to stir the pot again, but I can not think of a single instance, in a high level programming language, where I would use goto explicitly over a control structure or similar way of controlling program flow.


There's just no need.

[Dogstopper]

EDIT: I read Linus's ideas, very different than I thought!

This post has been edited by Dogstopper: 18 November 2009 - 07:01 PM

[carltech]

as long as your code is easy to follow then why not have a goto? I use jmp statements in assembler and well document my code for easy follow. If I needed to use goto in C then I would well document what happens and why. In C++ however there is no need for a goto statement in any well thought out code.

In short I agree with Linus in the above link...don't let someone's personal preference dissuade you from doing what makes your code more efficient and more readable.

[Bench]

From what i've seen, goto is primarily used for writing quick hassle-free fixes/enhancements to a bit of code where the developer is following the "if it ain't broke don't fix" philosophy;

In other words, they don't want to rewrite a largeish block of code because additional time will then need to go into peer reviewing and testing of code which may otherwise have not needed to change for a minor tweak.

This is a double-edged sword, because the existance of 1 goto in a block of code will often encourage future enhancements to be built in the same vein; Depending how often that function's logic needs to change, it doesn't take too long before a simple quick-fix gets messy. Eventually the day comes when something is so indecipherable and inter-locked with dependencies that rewriting it becomes a major task needing many development and testing hours.

just to illustrate what sometimes happens when several different developers get their hand on some 'goto' code, stealing Polymath's example (I've seen worse examples than this in production code...)

while(condition) {
   do_crap();
   if (exit_condition) {
      //we have an error!
      goto exit_loop;
   }
   else if(exit_condition2) {
       //we have a different error!
       goto exit_loop2;
   }
   for (blah) {
      do_other_crap();
      do {
         blah;
         if (exit_condition_3) {
             //we have an error!
            goto exit_loop;
         }
      } while (yet_another_condition);
   }
   do_yet_more_crap();
   if(exit_condition_4)
      goto exit_loop2;
   //here insert more crap...
}
exit_loop:
// stuff for exit_loop
goto exit_loop3;
exit_loop2:
//stuff for exit_loop2
exit_loop3: 

In an ideal world, I would always opt for re-designing away from 'goto' sooner rather than later (but of course business considerations trump technical ones). I can think of few people who would enjoy the task of tracing through dozens of lines of such code as you can see above.

Again, it comes down to individual programmers and their own judgement - if the boss wants something done 5 minutes ago, it might be a choice between a quick 'goto' fix and the boss having to explain to senior management why an airtight deadline worth £XXXXX has been put back by a day (In which case the boss will probably make that rather easy choice for you)

[CTphpnwb]

Bench, on 26 Nov, 2009 - 09:54 AM, said:

In an ideal world, I would always opt for re-designing away from 'goto' sooner rather than later (but of course business considerations trump technical ones).

This is one of many areas where the typical short-term business mindset ends up costing more than it saves. Taking the time to do things right is the way to save money and time. Inserting a quick goto now may seem like a cost efficient solution, but the trouble it will cause later far offsets any short term gains.