Return Styles: Pseud0ch, Terminal, Valhalla, NES, Geocities, Blue Moon.

Pages: 1-

GOTO

Name: Anonymous 2010-10-26 22:52

    why do people hate gotos again? my prof said it decreases readability but.....

    Top:


    ........


    goto Top;

    GEE WONDER WHAT THE FUCK I DO IM SO FUCKING STUMPED AS TO WHAT THE PROGRAM WILL DO HERE

    I mean really why are they so bad?

Name: Anonymous 2010-10-26 22:53

ONE WORD THE FORCED INDENTATION OF POST. THREAD OVER

Name: Anonymous 2010-10-26 23:16

Goto isn't much of a problem when you're writing 20 line programs, but in larger programs, it really does become a clusterfuck. Trust me on this.

Name: Anonymous 2010-10-26 23:19

VALID PERL CODE

Name: Anonymous 2010-10-27 0:03

because nested GOTO

Name: Anonymous 2010-10-27 0:31

Because ENTERPRISE QUALITY

void ENTERPRISE_C()
{
    int err = 0;
    char *buf1 = malloc(1);

    err = func1(buf1);
    if (!err)
    {
        char *buf2 = malloc(2);
        err = func2(buf1, buf2);
        if (!err)
        {
            err = func3();
            if (!err)
            {
                err = func4(buf2);
            }
        }
        free(buf2);
    }
    free(buf1);
}


is much more readable than the equivalent using a goto to jump to a cleanup in case of an error. Especially as functions get larger.

Name: Anonymous 2010-10-27 0:34

>>6
You must be joking.

Name: Anonymous 2010-10-27 0:55

>>7
nest if statements considered harmful

Name: Anonymous 2010-10-27 5:53

>>6
CAN YOU HEAR ME UP THERE FROM THAT NESTED PYRAMID OF ITS OF YOURS? I THINK YOU'RE WRONG. I THINK WHEN TO VIEW CODE YOU HAVE TO SCROLL RIGHT IT'S NOT OKAY.

Name: Anonymous 2010-10-27 8:02

GOTO without ALTER is waste of a keyword.

Name: Anonymous 2010-10-27 9:06

>>1
Please read "GOTO Considered Harmful" for the origin of this.
When you can pick a random point in a program and jump to it, you have can no longer have guarantees about what the state of the program is at any given moment. This is the reason that gotos in "modern" languages are restricted.
And in the usual case, higher level control constructs better express your intent and save you from having to make up stupid labels which just clutter up your program.

Name: Anonymous 2010-10-27 9:08

>>11
You helped him!

Name: Anonymous 2010-10-27 10:08

>>1
Listen to >>11 but keep in mind that goto can save you a lot of code, readability, and sometimes speed in tight loops.
grep -rI goto /usr/src/linux

Name: Anonymous 2010-10-27 11:03

>>7
No shit.

Name: Anonymous 2010-10-27 14:02

I usually only use goto (or its equivalents in other languages) for these purposes:
1) When breaking out of nested loops in C-like languages which don't provide multi-level break/exit statements/operators (some fancier languages do provide much better solutions for this, Common Lisp comes to mind almost immediately). Also used for cleanup/error handling in C as well when it makes sense to do so. Usually you should only use goto (or equivalents) when you can't use a more specific statement that the language provides to solve the problem. Of course, you can in many cases avoid goto by adding useless conditionals (which could slow down the code), but since that new code is not semantically equivalent to the one with the most straightforward goto, it's usually a fine use scenario.
2) For performance reasons in certain very tight loops. It can be a great time saver if the only alternative is to add a conditional which would have to get executed a lot more often and thus diminishing the overall performance, possibly by quite a lot. (One notable example that happened to me was some crypto bruteforce code where every memory access and compare counts. It got a 3 times speedup, leading to results being found in 1.5 minutes as opposed to 4-5min).
3) In generated code. There's absolutely no shame in using goto's here as all compilers do translate a lot of control-flow constructs to goto's (or jumps if you wish). I've used it quite a few times in CL macros. The gotos themselves don't obscure the intent of the code as they're not really visible (they're internal details that the compiler will have to handle, and the labels are gensyms anyway). Of course, TCO+lambda is more powerful than goto, and throw/catch, block/return-from, ... are also more powerful than it, but they can also be overkill (stack unwinding), however I fear discussing this further won't really help OP much as this is far from the usual C territory (albeit, you can achieve a lot of this in C, some as is, other with compiler hacking, but if you do that, all bets are off anyway).
4) Another legitimate case are state machines, a lot of times they can be described most naturally by the use of goto, and their translation is most natural. One could probably say the same for translating code written in other languages or obscure assemblies (both automatic translation or manual). For example, you could translate some of Knuth's olde recipes. Of course, most of Knuth's algorithms can be written in goto form if you translate them directly, but then you can rewrite them in a way that makes more sense and is properly structured code, however having the option to do it either way is useful.

Name: Anonymous 2010-10-27 14:08

When I moved to Lunix and was learning bash, I saw bash's break and I was "Of course!".

Name: Anonymous 2010-10-27 14:32

>>15
You are awesome.

Name: Anonymous 2010-10-27 15:24

>>15
State machines? Really? I'd have used some kind of function table.

Name: Anonymous 2010-10-27 16:20

goto considered harmful is the reason we have ``recursive" programming and compiler ``optimization".

goto loves you too.

Name: Anonymous 2010-10-27 16:21

>>17
Unlike yourself.

Name: Anonymous 2010-10-27 16:41

>>19
"oh no not recursion remember the good old days when you knew exactly the size of the stack at any one point remember those days well they were good weren't they"

Name: Anonymous 2010-10-27 17:06

>>15
4) Use maps of inputs to function and a language/compiler that support TCO.

Name: Anonymous 2010-10-27 17:16

>>19,21
I'm not sure what you're talking about, but the scary part is that you are not sure either.

Name: Anonymous 2010-10-27 17:42

>>22,18
There's a lot of ways of handling state machines. For large ones, I tend to use the more high-level approach (such as chained lambda's that take advantage of TCO), however for small ones, using go(to) is pretty straightforward and does not seem in any way bad since it naturally expresses the state transition.

Name: Anonymous 2010-10-27 17:57

>>23
No, no, it's just you. And maybe >>19.

Name: Anonymous 2010-10-27 23:44

goto The GOTO;

Name: Anonymous 2010-10-28 6:33

goto >>1

Name: Anonymous 2010-10-28 8:39

comefrom >>27

Name: Anonymous 2010-10-28 12:29

goto>>29

Name: Anonymous 2010-10-28 14:56

goto NULL;

Name: Anonymous 2010-12-21 1:48


Don't change these.
Name: Email:
Entire Thread Thread List