goto and labels

1
2
3
4
5
6
7
8
9
10
11
12
13
14
BYTE var = 0;
var = some_global_variable;
if(var == 1)
{
var2 = another_global_variable;
if(!var2)
goto label_1;

//some code here

}
else//Since theres no {...} here is label_1 not taking the else space?
label_1:
var = 0;


Is the code above using goto safely, and at else there is no {...} there so because of that will label_1 take the else space or will var = 0 take it? i don't want the code that goes into if(var == 1) to be set to var = 0 at the end, so is that safe?
Most uses of goto are poor. This is a poor use of goto.

You really should avoid using it. (usage of globals is something else that should be avoided, but that's another topic)

A better approach would be to just arrange your conditionals differntly. This has the same effect, but is much easier to understand and follow:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
bool zerovar = true;  // maybe name it something better

BYTE var = 0;
var = some_global_variable;
if(var == 1)
{
  var2 = another_global_variable;
  if(var2)
  {
    zerovar = false;
    // some code here
  }
}

if(zerovar)
  var = 0;


Or... since all that label does it zero var, you could just zero var directly instead of having a separate condition for it:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
BYTE var = 0;
var = some_global_variable;
if(var == 1)
{
  var2 = another_global_variable;
  if(var2)
  {
    // some code here
  }
  else
    var = 0;
}
else
  var = 0;



So yeah -- get rid of that goto crap.
Thanks for replying, but why is goto so bad? i have used it sometimes and when i have, have not had any problems with it

and also in my above example is else label_1 or var = 0?
Last edited on
but why is goto so bad?


It's confusing. It makes your code a twisted mess and makes the logic hard to follow. It's much more intuitive when the flow goes cleanly "downward" in your code. With goto it hops all around and it's difficult to keep straight.

i have used it sometimes and when i have, have not had any problems with it


Code always makes sense to you as you're writing it. But if someone else were to look at your code they would have a harder time understanding it.

For example -- posting code on these forums for help. You're more likely to get help if people can understand the code you're posting.

But it's not just for other people. When you step away from a project for a few weeks/months and then come back to it with fresh eyes, you'll have forgotten a lot of what you had fresh in your mind when you originally wrote it. Code that made perfect sense to you at the time suddenly makes you scratch your head and wonder "what the hell was I trying to do here?"

and also in my above example is else label_1 or var = 0?


This is another reason why it's confusing and should be avoided.

Really... I honestly don't know. I would guess that var = 0; would be inside of the else. It could easily be tested.

But again -- just avoid this.
Last edited on
It is also important to avoid goto on another level: it is harder to reason about code with gotos, so your compiler may produce less-optimized code when you have them.

A goto is a lazy way of thinking about code. If you organize your code properly, you should only find rare use for them.

Hope this helps.
Nice explanation, Duoas.
Long long time ago I read an article about this goto statement. It implies this is used often in assembly language instruction program. Then somehow when C was created, the creators decide to port that over too. I would presume could this be a way to 'lure' assembly language programmers to migrate to a "high-level language" like C back in the 70's ?


Not quite. In assembly the only flow control is a "goto" (or branch aka "jump") instruction. There are always at least two forms: unconditional and some form of conditional. (The x86 architecture provides quite a few of these, while others, like RISC, only have one or two.)

In any case, the problem wasn't with assembly languages, but with the extant HLLs, like 00FORTRAN (please pardon02 my dau01ghter is sharing my kbd atm).,+++ and BASIC, which had, essentially, no structure outside of what the programmer imposed on it with judicious (or, as often as not) foolish use of the GOTO.


The "structured language wars" (so called, as they were waged to exterminate unstructured languages) often gave an excessively negative portrayal of GOTO and those who used it. I don't deny that it was often accurate, but the fallout continues today when people start some hate rant against the "goto" instead of blasting idiots for using it improperly (and/or the idiots who taught the poor sap to use it improperly).

Related reading:
http://www.cplusplus.com/forum/beginner/2287/#msg8654

Enjoy!
Topic archived. No new replies allowed.