# C++ - Is Goto a Good Practice?

This topic is 1892 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

goto is not evil in and of itself. There are some very rare occasions when a carefully placed goto can save you a lot of time.

The problem is that goto is essentially an intrinsic for the 'jmp' instruction. If you're good with assembly and understand stack frames and the general behavior of the compiler then you can get away with it, but otherwise just do whatever you have to do to avoid it. The risk of unexpectedly dragging invalid state into somewhere that it doesn't belong (and not having the correct state established for that location) is simply too great.

Even if you do have a perfect grasp of the mechanics and implement a correct use of goto then you'll probably only do it either as a temporary measure or else as some form of bizarre optimization accompanied by 3 pages of commenting.

##### Share on other sites
If goto would be that bad it wouldnt exist. Its better not to use it for jumping through long code though .....especially if many people are working on the same code.
+(Ive worked at 2 big companies ....neither allowed to use goto:))

##### Share on other sites
Aliii: Some things exist as an evil legacy from the dark times.

##### Share on other sites

As far as I know there is no case where a goto in C++ is the best tool for the job.

The only thing I can think of is for the output of automatic code generators such as lexers and parsers. It produces unmaintainable spaghetti code, but it doesn't matter because it's not meant to be maintained by human hands.

##### Share on other sites
Basically there's no reason to use "goto" unless your code's workflow is incorrect.

##### Share on other sites

Aliii: Some things exist as an evil legacy from the dark times.

I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)

##### Share on other sites

[quote name='rnlf' timestamp='1352909335' post='5000944']
Aliii: Some things exist as an evil legacy from the dark times.

I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
[/quote]

People don't just avoid code mechanisms without a reason, in my experience there's always a better and cleaner way to solve a problem than by using goto.
And there are definitely "dark ages", C and C++ have been around for quite a while now, and both languages have evolved a lot, so it's only natural that there are features in both which have somewhat of a legacy.

##### Share on other sites
I think you've probably got your answer by now, but just to give my two cents - the use of GOTO in C++ can completely undermine the object oriented design of the language, which is after all the whole point.

##### Share on other sites

[quote name='Aliii' timestamp='1352923452' post='5000998']
[quote name='rnlf' timestamp='1352909335' post='5000944']
Aliii: Some things exist as an evil legacy from the dark times.

I know that. But theres no "dark times" here ....many people are just allergic to goto I think:)
[/quote]

People don't just avoid code mechanisms without a reason, in my experience there's always a better and cleaner way to solve a problem than by using goto.
And there are definitely "dark ages", C and C++ have been around for quite a while now, and both languages have evolved a lot, so it's only natural that there are features in both which have somewhat of a legacy.
[/quote]

It always worked fine for me. I wonder how many of those people who blame it actually used it and had all those horrible things happen to them ...and to their code. (Maybe no one:)

Of course dont use it when working in a team, dont use it in functions that are more than lets say 60 lines, ....and dont combine it with lots of break, continue, recursion and function pointers.

##### Share on other sites

*snip*

It's already a warning sign if you have to make a list of some quite common and maybe essential language features you shouldn't use together with goto, just saying.

Here's another one for the list:
Using goto statements can make it really damn hard to prove the correctness of your program since it completely allows you to break your program's structure. Not being able to prove that your program works as it's supposed to will send you straight to debugging hell, and that's one place you really don't want to be.

Maybe using lots of goto statements works for you, but I can think of hundreds of designs which would also work but which would be horrible to maintain, extend and debug. We don't advise against using goto because we have some sort of weird prejudice against it, we advise against it because when it comes to C++ in almost all the cases there's a better and cleaner tool for the job.

And no I'm going to stop, I'm starting to ramble...

##### Share on other sites
"It's already a warning sign if you have to make a list of some quite common and maybe essential language features you shouldn't use together with goto, just saying."
....it was not a Dont-use-this-with-goto-Bible and I didnt have to make it:) ....I just gave some examples.(I think they are quite accurate though.) Plus I used the words "lots of" but nevermind

"Maybe using lots of goto statements works for you"
It doesnt, because I dont use lots of goto.

I dont wanna argue, Ive just told my experiences with goto. You almost seem like atacking me for it.

##### Share on other sites
It seems like people are mostly agreeing that goto should be avoided whenever possible and the program structure questioned otherwise.

Hopefully we don't need another 'little scene'. (Though I have to admit they can be pretty amusing.)

##### Share on other sites
As long as a language has [font=courier new,courier,monospace]goto[/font], it isn't intrinsically bad to use it.

It is possible to use it either in a right or in a wrong way.

The thing is that as a language has a higher level than others, it is in general spontaneously easier and natural to avoid using [font=courier new,courier,monospace]goto[/font].

__________________________________________________
__________________________________________________
__________________________________________________
I am currently mainly an x86 Assembly language programmer but I can program a bit of C, Pascal, and a good amount of JavaScript and PHP, so I can tell you that in languages higher than Assembly (including C) I rarely use [font=courier new,courier,monospace]goto[/font]. It might seem paradoxical but Assembly language has helped me no end to find ways to program very elegantly and concisely without using [font=courier new,courier,monospace]goto[/font], or excessive nested [font=courier new,courier,monospace]if[/font]s or nested function calls.

Now, I find myself all the time converting higher-level code to Assembly by hand. In that case, you can see that down to the bare metal level all of your loops, conditional code and the like, must be converted to conditional Assembly instructions that work exactly like [font=courier new,courier,monospace]goto[/font], and in general it can't be avoided at that point (which by the way is by no means an obsolete environment but just the very essence of a machine).

I also find myself converting Assembly code to higher-level code, and in this case I must find ways to do it efficiently. I almost never need to use [font=courier new,courier,monospace]goto[/font] when doing this.

In other words, knowing how to use [font=courier new,courier,monospace]goto[/font] properly is necessary, not to be abused and not to be ignored either (specially if you know and want to use Assembly language, among other things, to work a little bit in designing or understanding compiler-like programs that generate Assembly code).

If you use it too much in a high-level language, chances are that you are still in a very incipient level of knowledge for a proper implementation of your logic when you could use syntax elements better suited for what you want to achieve in that language (e.g., using [font=courier new,courier,monospace]goto[/font] for no special reason when you could have used a [font=courier new,courier,monospace]while[/font] loop that maybe you just didn't know how to use).

##### Share on other sites
It might seem paradoxical but Assembly language has helped me no end to find ways to program very elegantly and concisely without using [font=courier new,courier,monospace]goto[/font], or excessive nested [font=courier new,courier,monospace]if[/font]s or nested function calls.

I've also noticed this in my own coding. I think part of it is the inversion of the logic with conditional jumps. Somehow just doing a little bit of work with that subconsciously reorganized my brain and now my loops and conditionals come out smoother. It's strange that the inversion is unintuitive but somehow results in a better 'natural flow' once it's understood.

##### Share on other sites
Only skimmed through the topic,

In a game menu scenario I would go with a finite state machine of game states and loop through it accordingly.

##### Share on other sites
A small remark - the guys who dislike goto are on the forums whining about it while the guys who like goto are actually coding something.

Which do you want to be?

(EDIT: Another small remark - guys around here seem to have no clue about the concept of humour!) Edited by powly k

##### Share on other sites

... the guys who dislike goto are on the forums whining about it while the guys who like goto are actually coding something.
[/quote]
Wow. That is an impressively simplistic false dichotomy.

##### Share on other sites
... or a bad joke And though I (seriously) don't think goto is bad by default, I've never had a reason to use it.

##### Share on other sites
I think one of the only times I ever used goto was to get out of a three-level nested loop. It wasn't final code and I couldn't be bothered to add break flags or put the loops in their own function, so I just used goto as an extended break. But I wouldn't recommend it - it's not really compatible with higher level control flow, but it's nice to know it exists.

I'm sure there are instances out there where goto may in fact be beneficial (someone mentioned cleaning up C functions, which is a good one, of course you can achieve the same goal by carefully nesting your allocations but sometimes goto is the only elegant way to do it), but you certainly don't use goto "just because you can".

##### Share on other sites
Say no to goto!~~

heehee.

##### Share on other sites
I don't actually know what happens in the following scenarios. Does goto respect rules of the scoped objects?
 { std::string tee("hee"); goto forward; } forward: // what happens with destruction of tee? Memory leak I guess. backward: // what happens with destruction of tee? Memory leak I guess. int i = 0; if (i == 0) { i = 1; std::string tee("hee"); goto backward; } if (rand()%2 == 0) goto forward2; { std::string tee("hee"); forward2: // tee isn't constructed here with goto. Crash if referenced I guess. // tee must be destructed at scope exit if entered without goto. } 

Does goto break all RAII objects? Edited by Codarki

##### Share on other sites
A goto out of a block destroys all objects that have been initialized in that block. A goto into a block after a statement creating an object with an initializer is ill-formed (i.e. the compiler should bitch at you for trying it). So in your specific scenario, the first goto to forward should properly destroy tee. The goto to backward will destroy the second tee because control flow still leaves that block. The goto to forward2 should trigger a compiler error.