Goto's?

[MrViggy]

Is it me, or has anyone else noticed an increased use of 'goto's in posted C/C++ code lately?

Viggy

[wildfrog]

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

[TheCPUWizard]

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 :D

[MrViggy]

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
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. :D

Viggy

[S_M_A]

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?

[wildfrog]

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:

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

[TheCPUWizard]

NOOO! Don't go there!!! :eek:

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??


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;
}


So "f(42)" = ???? :eek: :eek: :sick:

[wildfrog]

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

[MikeAThon]

... 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. ...
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.)

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.

[Kheun]

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".

[TheCPUWizard]

PS: Wouldn't a "comes_from" statement make an exciting addition to C and C++!! Maybe the standards committee would be interested.

Actually, the language Zepher (obscure test instrumentation language from the late 1970's DID have a "ComeFrom/Return" construct. :eek:

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.

[SuperKoko]

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.

But, it looks like the war is going to start...
I don't think you're responsible.

[S_M_A]

But, it looks like the war is going to start...
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.

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): :)
switch(selector)
{
case 0:
...
if( othervar ) break;
case 1:
...
break;
.......
}

[JohnW@Wessex]

It's nothing worse than changing state in a switch-statement, or using break/continue in a loop.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.

[TheCPUWizard]

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.

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.

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).

[wildfrog]

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.
Well, actually when you got multiple continues/break within a loop you may lose track.

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.


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?


- petter

[S_M_A]

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.

[SuperKoko]

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.

Your compiler is buggy:

#include <iostream>

int main() {
goto next;
int x=42; /* initializer or constructor */
next: std::cout << x;
}


Is ill-formed code.
A diagnostic message is required.
Most compilers generate a fatal diagnostic message (i.e. an error), which is a good thing.

[TheCPUWizard]

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:


"f(42)" = ????


:D

[MikeAThon]

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:

D@mn!! If it wasn't for all those gotos, we would have been able to figure it out!!

Mike

[exterminator]

See this - http://groups.google.co.in/group/comp.lang.c++.moderated/browse_frm/thread/634c70a74a925f12/

[ChaosTheEternal]

Guess no one is going to tell me what the "Ultimate Question" was?? :( If it weren't for the division by 0 and the missing label, then maybe you'd be able to figure it out.

Of course, that's assuming there's nothing fundamentally wrong with the Universe.

[ahoodin]

42:goto question

[TheCPUWizard]

If it weren't for the division by 0 and the missing label, then maybe you'd be able to figure it out.

Of course, that's assuming there's nothing fundamentally wrong with the Universe.

OK, i fixed the missing label (d) :blush:

But I dont see a divide by 0... :confused: :confused:

[ChaosTheEternal]

But I dont see a divide by 0... :confused: :confused://...
goto b;
e:
if (x % 0)
goto b;
//...
Dev-C++, using the g++ compiler, gives a warning about it being a Divide by 0.
VS2005 gives the warning "potential mod by 0", but since it is Modulus division, it's still dividing by 0.

[TheCPUWizard]

Dev-C++, using the g++ compiler, gives a warning about it being a Divide by 0.
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.

Yes "(x%0)" is mathematically undefined, I actually meant to use the much more useful "(x%1)"... (going back to edit again)....

[ChaosTheEternal]

Told you "I didnt see it", did not say it didnt exist.I had to type something, and I hate just saying "Here".

[S_M_A]

I sense that this thread is going from "potential goto war" -> "it's friday"... ;)

[TheCPUWizard]

I sense that this thread is going from "potential goto war" -> "it's friday"... ;)

Nope..after midnight, now saturday!!!!

[wildfrog]

Yep, it's Saturday 'morning' (strangely enough I can feel that in my bones, muscles, limbs and head...).

Your compiler is buggy:You're right. I'm using VC++ 2005.

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