Is it me, or has anyone else noticed an increased use of 'goto's in posted C/C++ code lately?
Viggy
Printable View
Is it me, or has anyone else noticed an increased use of 'goto's in posted C/C++ code lately?
Viggy
Actually I was thinking the same just minutes ago. Yes, there are more gotos these days.
But I'm not sure it's time for another goto-flame-war ;)
- petter
War Chant, War Chant, (Painting Face & Body), War Chant, War Chant :DQuote:
Originally Posted by wildfrog
Sorry, it wasn't my intent to start a flame war. Just an observation over the past few days. I thought maybe it was me. :DQuote:
Originally Posted by wildfrog
Viggy
I don't have enough history on CG to tell but anyway, isn't goto more or less accepted these days when it comes to "on-error clean-up before return" in C?
NOOO! Don't go there!!! :eek:Quote:
Originally Posted by S_M_A
Ok, It's too late. I honestly don't care about Dijkstra-or-what-ever-his-name-was-back-in-69. I pay my bills, and I use goto. It's nothing worse than changing state in a switch-statement, or using break/continue in a loop.
Living dangerous,
Petter
Really??Quote:
Originally Posted by wildfrog
So "f(42)" = ???? :eek: :eek: :sick:Code:int f(int x)
{
goto a
c:
++x;
goto d:
f:
if (x>100)
return x;
else
goto a;
b:
for(int i=0; i<x; x /=2) {}
goto c;
a:
x += 2;
goto b;
e:
if (x % 0)
goto b;
else
goto f;
d:
x /= 2;
goto e;
}
No, but that is a flaw in the language :rolleyes:. They managed to solve this for select statements where attempts to jump over variable declarations are forcefully prohibited...
BTW, you cannot just end a war like that... like in seconds. :D
EDIT: select? I mean switch... time for bed.
- petter
I used to feel the same way. In my mind, there was no principled, moral difference between a goto and (say) multiple or early returns from a function, continue or break from a loop, or a switch statement. After all, when you're maintaining code, and you see a goto, you know exactly where you're going to. (Note that these discussions should always consider the perspective of code maintenance, not code authoring, since maintenance is where the complications usually arise.)Quote:
Originally Posted by wildfrog
Then someone pointed out that the problem with goto is not the goto itself, but rather the labelled statement where the goto arrives. When maintaining code, if you encounter a labelled statement in a routine with gotos, you have absolutely no idea of how the code might arrive at the label, and what state the code arrives in. One way of thinking about this, is that the problem with goto is really a problem in understanding where the code came from. In other words, the problem is not the goto per se, but rather the problem is the comes from.
The other code constructs (like break and switch and continue) do not suffer from the "comes from" problem. You know exactly where the code is coming from, and its exact state when it arrives.
So, I'm now leaning towards the goto-less camp. I still use an occassional goto in extremely limited and clear situations, where maintenance is not a problem, but I'll avoid a goto otherwise.
Mike
PS: Wouldn't a "comes_from" statement make an exciting addition to C and C++!! Maybe the standards committee would be interested.
As long as I am coding in C++, I don't think I will ever need to use goto statement. Unfortunately, in C, due to it lack of support for RAII and exception functionality, sometime I have to resort to goto statement for common resource deallocation code before returning from function. In other words, I mean goto statement still has its use but we have to "handle with care".
Actually, the language Zepher (obscure test instrumentation language from the late 1970's DID have a "ComeFrom/Return" construct. :eek:Quote:
Originally Posted by MikeAThon
The way it worked was that you could declare a Subroutine with a ComeFrom statement which took 2 parameters. The first was the name of another subroutine [No OOP in those days :) ] as well as an "AtEnter/AtExit" parameter.
This would insert the declared routine as either a pre-process or a post-process handler for the designated routine.
The advantage of this construct was that you did not need to modify (or even have) the source for the code you were "injecting" the additional functionallity.
But, it looks like the war is going to start...Quote:
Originally Posted by MrViggy
I don't think you're responsible.
No, in that case I'm the responsible. However, I'm glad to see that all the posts are very peaceful.Quote:
Originally Posted by SuperKoko
Interesting to read the input from you pros. Personally I kind of like the "on-error clean-up before return" usage. I find the resulting code to be cleaner (easier to read) without a couple of if/clean-up/returns and thus easier to maintain. Of course the freedom to use goto for this also comes with restrictions but that's also true for a lot of other code constructs. After all, I don't think anyone here would promote (real life example from a code review): :)Code:switch(selector)
{
case 0:
...
if( othervar ) break;
case 1:
...
break;
.......
}
I don't ever use goto and, I don't use those in a loop either. Maybe it's the way my brain works, but find that break/continue in loops obfuscates the overall flow of the code.Quote:
Originally Posted by wildfrog
Same here. If you extract all logic from loops to functions/methods, and have the loop be nothing but flow control it is so much easier.Quote:
Originally Posted by JohnW@Wessex
The same is true for "if" and "switch" statements. I attempt to never let the "conditional" bart exceed 3 lines (not counding braces (for if) or case/break (for switch).