Thread: Is GOTO a bad idea ever?

Hi all!

Well programmers are unanimous when it comes to use the goto keyword: everybody aggrees it's a bad idea to use it AT ALL.

Is that really true? For example, this code:

Code:

int main()
{
    for( ; ; )
    {
        RoutineA();
        RoutineB();
        RoutineC();
    }
}

Works well on most compilers, but I find the

Code:

int main()
{
    MyRoutines:
        RoutineA();
        RoutineB();
        RoutineC();
    goto MyRoutines;
}

a more cross-platform aproach (when compiling the same code in different compilers, for example. Note that the for statement, when used without parameters, is not accepted in every compiler).

Well is goto a REALLY bad idea as many people say?
Is there any author in related literature who mentions this subject satisfactory?
What are the cases I could precisely use it?

Originally Posted by artur

Is there any author in related literature who mentions this subject satisfactory?

Search for "Goto considered harmful".
There is a historical paper by Djikstra in that name.

What are the cases I could precisely use it?

Afaik, it is sometimes used for error handling and avoiding flaggy code.
I myself have no problem with flaggy code, however.

I've heard some people say that there are some legitimate uses for goto, but personally I've never been presented a convincing case.

Originally Posted by oogabooga

You would have to be truly retarded not to see that goto is better in this case:

Code:

// with goto
while (whatever) {
    while (something) {
        if (such_and_such)
            goto break_outer_while;
        actual_work();
    }
}
break_outer_while:

// with idiotic flag
while (whatever && !idiotic_flag) {
    while (something && !idiotic_flag) {
        if (such_and_such)
            idiotic_flag = 1;
        else {
            actual_work();
        }
    }
}

If the outer while needed to clean up something, the goto version would've needed a few "idiotic_label"s !

Originally Posted by oogabooga

You would have to be truly retarded not to see that goto is better in this case:

Code:

// with goto
while (whatever) {
    while (something) {
        if (such_and_such)
            goto break_outer_while;
        actual_work();
    }
}
break_outer_while:

// with idiotic flag
while (whatever && !idiotic_flag) {
    while (something && !idiotic_flag) {
        if (such_and_such)
            idiotic_flag = 1;
        else {
            actual_work();
        }
    }
}

Code:

void func()
{
    while (whatever) {
        while (something) {
            if (such_and_such)
                return; // <-- no goto needed
            actual_work();
        }
    }
}

a better alternative would be to put the whole nested loop construct in its own function, and when the condition occurs that requires breaking out of both loops, you simply return. very clean, very simple, very clear. in C++, you have the additional option of throwing an exception that gets caught outside the nested loop, but in C, I think the return from function is the best solution for the nested loop.

Originally Posted by TheBigH

But then you have to pass the variables that "whatever", "something", and "such_and_such" depend on to the function. Even assuming this situation could be handled with a void func(void), oogabooga's solution with the goto is clearer to me, because of the intelligent choice of label name.

If I saw a function call like the one you suggest in someone else's code, I would think "You made me scroll all the way to the bottom to look at this function and then all the way back to where I was, just so you could avoid using a goto that would jump forward maybe three lines. Riiiiiiiight."

Moving all that stuff out to a separate function encourages an approach to programming that emphasizes breaking down problems into small, manageable pieces that can be developed, debugged and reasoned about in isolation from the rest of the program. I think that's a very good thing.

I'm so tired of dealing with functions spanning several screen pages and containing dozens of variables, loops, if-else cascades, etc.

After reading the whole discussion so far i believe that there are certain cases, like the one oogabooga proposed, in which the use of a goto statement could be considered not harmful in order to make a more simple and readable code. In my particular case i try to avoid the use of a go to statement because i prefer that the logical structure of my program decides wich control flow should be executed by the program, i do this because i can predict the way the program is going to work and my debug of the program is simpler. What i really oppose is the abuse of the go to at least in a high language program.