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).
Well, actually when you got multiple continues/break within a loop you may lose track.Quote:
Originally Posted by MikeAThon
The major problem with 'goto' is IMO what TheCPUWizard mentioned. That you can easily jump over variable declaration/definition/initialization without ever being notified (not even a warning) and that may lead to strange results.
I see the "comes from" problem all the time, and to me it just another issue that I have to deal with when debugging.
- petterCode:int i = // some value
while (i > 0)
{
// do something...
}
// at this point i =< 0. How can I know if the above loop was ever entered?
// And if it was, how many iterations were there?
I sure don't regret risking that war! This was interesting reading. :)
I have to admit that I have never given much thought of how and why to get rid of break & continue in loops. Maybe I have seen them for so long that I'm just take their neccessity (and how is that spelled...) for being a law of nature but now I see your points.
Your compiler is buggy:Quote:
Originally Posted by wildfrog
Is ill-formed code.Code:#include <iostream>
int main() {
goto next;
int x=42; /* initializer or constructor */
next: std::cout << x;
}
A diagnostic message is required.
Most compilers generate a fatal diagnostic message (i.e. an error), which is a good thing.
Guess no one is going to tell me what the "Ultimate Question" was?? :(
[reference to Hitchhikers Guide to the Galaxy....]
The "Ultimate Anwer" we know to be 42, so my code posted above, should give the question:
:DQuote:
"f(42)" = ????
D@mn!! If it wasn't for all those gotos, we would have been able to figure it out!!Quote:
Originally Posted by TheCPUWizard
Mike
If it weren't for the division by 0 and the missing label, then maybe you'd be able to figure it out.Quote:
Originally Posted by TheCPUWizard
Of course, that's assuming there's nothing fundamentally wrong with the Universe.
42:goto question
OK, i fixed the missing label (d) :blush:Quote:
Originally Posted by ChaosTheEternal
But I dont see a divide by 0... :confused: :confused:
Quote:
Originally Posted by TheCPUWizard
Dev-C++, using the g++ compiler, gives a warning about it being a Divide by 0.Quote:
Code://...
goto b;
e:
if (x % 0)
goto b;
//...
VS2005 gives the warning "potential mod by 0", but since it is Modulus division, it's still dividing by 0.
Told you "I didnt see it", did not say it didnt exist.Quote:
Originally Posted by ChaosTheEternal
Yes "(x%0)" is mathematically undefined, I actually meant to use the much more useful "(x%1)"... (going back to edit again)....
I had to type something, and I hate just saying "Here".Quote:
Originally Posted by TheCPUWizard
I sense that this thread is going from "potential goto war" -> "it's friday"... ;)
Nope..after midnight, now saturday!!!!Quote:
Originally Posted by S_M_A
Yep, it's Saturday 'morning' (strangely enough I can feel that in my bones, muscles, limbs and head...).
You're right. I'm using VC++ 2005.Quote:
Originally Posted by SuperKoko
I thought that TheCPUWizards code contained 'jumps over variable initializations', but when I look at the code now, I connot find it.. maybe it's been edited :confused:
- petter