Since goto is getting so popular these days....
-
Is the goto becoming popular? How silly. It's just a tool, just like any other keyword used for a predefined function. Mind you, I'm still pissed off that the C+ chaps refused my demand to have the return statement keyword changed to "otog" -- symmetry is so important in programming; it makes everything more understandable.
I wanna be a eunuchs developer! Pass me a bread knife!
Busog shurely
-
Busog shurely
Please don't call me Shurely.
I wanna be a eunuchs developer! Pass me a bread knife!
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
Why the bunch of univotes? Geeezzz... Guys.. joke, you know... the thing you do / say to have a laugh? I know some don't understand that concept, hence the Joke icon... :doh: Aaah... goto hell!
We are using Linux daily to UP our productivity - so UP yours!
-
I've NEVER held a religious view about goto. I do agree that overuse can make code unreadable. I've never used goto in my code, in 12 or so years of programming, because it's never been the best solution.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Christian Graus wrote:
I've never used goto in my code, in 12 or so years of programming
The last time I used
gotowas back in the early 90's, and then it was because exception handling wasn't implemented by the tool chain I had at the time.Software Zen:
delete this; -
I've NEVER held a religious view about goto. I do agree that overuse can make code unreadable. I've never used goto in my code, in 12 or so years of programming, because it's never been the best solution.
Christian Graus Driven to the arms of OSX by Vista. Read my blog to find out how I've worked around bugs in Microsoft tools and frameworks.
Never used GOTO writing MS-DOS batch files? Ok, I was 15 years old, but still, by then it was reasonable.
-
rastaVnuce wrote:
elegantly solvable by using goto
"elegant" and "goto" should not be in the same sentence. ;) Marc
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
Event though I do not use it I've heard it is useful in some scenarios since it does not backtrack the method execution, it was used in the past on single entry single exit methods.
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
No, you will not go to hell. You will go blind though.
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
Ignore people who say goto is bad. Don't use goto when it's bad. It should be clear to you when that is. Don't use goto when there's already a language construct that can be used *just as easily*. One place where I use goto without apology is to simulate a finally clause when exception handling is not part of the language, or is non standard. For instance, in C. It's a matter of style, but I prefer the second version below: BEFORE:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) { .... error = somefunc2(...., &r2); if ( !error ) { .... error = somefunc2(...., &r3); if ( !error ) { .... free( r3 ); } free( r2 ); } free( r1 ); }}
AFTER:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) goto error: .... error = somefunc2(...., &r2); if ( !error ) goto error: .... error = somefunc3(...., &r3); if ( !error ) goto error: ....error:
if ( r1 )
free( r1 );
if ( r2 )
free( r2 );
if ( r3 )
free( r3 );
}Yes, the second form can be constructed without the goto, by using a gated if along the way, but having all the clean up code in a single place is a nice feature.
-
Ignore people who say goto is bad. Don't use goto when it's bad. It should be clear to you when that is. Don't use goto when there's already a language construct that can be used *just as easily*. One place where I use goto without apology is to simulate a finally clause when exception handling is not part of the language, or is non standard. For instance, in C. It's a matter of style, but I prefer the second version below: BEFORE:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) { .... error = somefunc2(...., &r2); if ( !error ) { .... error = somefunc2(...., &r3); if ( !error ) { .... free( r3 ); } free( r2 ); } free( r1 ); }}
AFTER:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) goto error: .... error = somefunc2(...., &r2); if ( !error ) goto error: .... error = somefunc3(...., &r3); if ( !error ) goto error: ....error:
if ( r1 )
free( r1 );
if ( r2 )
free( r2 );
if ( r3 )
free( r3 );
}Yes, the second form can be constructed without the goto, by using a gated if along the way, but having all the clean up code in a single place is a nice feature.
-
I get that this is a joke question, but seriously, why so much debate about it? It messes with flow in a pretty unreadable way, and the whole point of modern (post 1950) computer languages is that you write for your colleagues (or your future self) so why do it? But we've all seen a lot worse[^], so goto isn't the devil incarnate... end of story(?)
"It messes with flow in a pretty unreadable way"? Really? You find a goto statement unreadable? It really doesn't get much easier to understand than a goto statement. As easy, or easier, than a function call (a function call could be in a place further away in the code, and thus slightly harder to track down, while a goto, if not done poorly, will be very close by.) This gets pretty silly. There's nothing inherently wrong with goto. This comes from efforts in the distant past to clean up spaghetti code - one of the tenets of "structured coding". From wikipedia: "Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed (and still disagrees[citation needed]) with abolishing the GOTO statement. In his 1974 paper, "Structured Programming with Goto Statements", he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing provability." There's another "rule" to have only 1 exit point from a procedure. Yet this can lead to badly structured (unreadable, unmaintainable), deeply nested if statements, especially where return code and error handling are concerned. Lacking a quick "return" call, I think a "goto" to an exit line would be appropriate. switch statements are glorified gotos, as are multiple return statements (just debug the procedure if you doubt that :-) )
-
Ignore people who say goto is bad. Don't use goto when it's bad. It should be clear to you when that is. Don't use goto when there's already a language construct that can be used *just as easily*. One place where I use goto without apology is to simulate a finally clause when exception handling is not part of the language, or is non standard. For instance, in C. It's a matter of style, but I prefer the second version below: BEFORE:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) { .... error = somefunc2(...., &r2); if ( !error ) { .... error = somefunc2(...., &r3); if ( !error ) { .... free( r3 ); } free( r2 ); } free( r1 ); }}
AFTER:
void far()
{
int error;
Resource *r1 = NULL, *r2 = NULL, *r3 = NULL;error = somefunc1(...., &r1); if ( !error ) goto error: .... error = somefunc2(...., &r2); if ( !error ) goto error: .... error = somefunc3(...., &r3); if ( !error ) goto error: ....error:
if ( r1 )
free( r1 );
if ( r2 )
free( r2 );
if ( r3 )
free( r3 );
}Yes, the second form can be constructed without the goto, by using a gated if along the way, but having all the clean up code in a single place is a nice feature.
That is a perfectly acceptable use of goto, as I mentioned in an earlier reply as well.
-
Jon Sagara Some see the glass as half-empty, some see the glass as half-full. I see the glass as too big. -- George Carlin .NET Blog | Personal Blog | Articles
Ahahaha!! I couldn't imagine a better fate. Do loop breaks also beg for a dinosaur attack, or is that more of a dozen-rats-at-your-ankles sort of offense?
-
"It messes with flow in a pretty unreadable way"? Really? You find a goto statement unreadable? It really doesn't get much easier to understand than a goto statement. As easy, or easier, than a function call (a function call could be in a place further away in the code, and thus slightly harder to track down, while a goto, if not done poorly, will be very close by.) This gets pretty silly. There's nothing inherently wrong with goto. This comes from efforts in the distant past to clean up spaghetti code - one of the tenets of "structured coding". From wikipedia: "Donald Knuth accepted the principle that programs must be written with provability in mind, but he disagreed (and still disagrees[citation needed]) with abolishing the GOTO statement. In his 1974 paper, "Structured Programming with Goto Statements", he gave examples where he believed that a direct jump leads to clearer and more efficient code without sacrificing provability." There's another "rule" to have only 1 exit point from a procedure. Yet this can lead to badly structured (unreadable, unmaintainable), deeply nested if statements, especially where return code and error handling are concerned. Lacking a quick "return" call, I think a "goto" to an exit line would be appropriate. switch statements are glorified gotos, as are multiple return statements (just debug the procedure if you doubt that :-) )
I don't think there is an inherent problem with goto, but it comes with a high potential for abuse. Goto tends to be employed to get around a logic problem. By circumventing program flow, these gotos tend to interfere with scalability. It is the Scooby Doo ending of the coding world. Stick a rubber goto mask on the only other human in the episode and blame those pesky kids.
-
I don't think there is an inherent problem with goto, but it comes with a high potential for abuse. Goto tends to be employed to get around a logic problem. By circumventing program flow, these gotos tend to interfere with scalability. It is the Scooby Doo ending of the coding world. Stick a rubber goto mask on the only other human in the episode and blame those pesky kids.
I guess I have a problem with saying things like "By circumventing program flow..." goto doesn't "circumvent" program flow, it IS program flow. That would be like saying functions and if statements "circumvent" program flow. They direct program flow as program flow must be directed. If it's directed incorrectly or confusingly, that's not a problem with a language construct, it's a problem with the algorithm or program design. It really doesn't get much easier to understand than "goto MyLabel;" If you can't read and understand that, you simply can't understand code or follow directions.
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!
you WILL use goto in any non-trivial batch file as a quick-and-dirty solution to a simple syatem problem (or just maybe you have moved on to Powershell or Python or whatever so can prove me wrong). Back in the old days, before exceptions, you might very well use GOTO in recovering from certain kinds of error conditions. This was especially problematic on the venerable Apple II which did not properly unwind the stack in these situations. In one application I had to save relevant state and decide on which point to re-enter the program to sensibly resume - I managed this without the spaghetti falling off the fork (as it were).
-
I guess I have a problem with saying things like "By circumventing program flow..." goto doesn't "circumvent" program flow, it IS program flow. That would be like saying functions and if statements "circumvent" program flow. They direct program flow as program flow must be directed. If it's directed incorrectly or confusingly, that's not a problem with a language construct, it's a problem with the algorithm or program design. It really doesn't get much easier to understand than "goto MyLabel;" If you can't read and understand that, you simply can't understand code or follow directions.
In addition to arguing semantics, I think you followed up on a lot of points I didn't make. Introducing a goto is usually employed as a quick fix that interferes with scalability. I don't think there is any debate there.
-
GWBasic was cool. I did an awesome app in it wayyyy back in the day.
Everything makes sense in someone's mind
-
I have a problem which is elegantly solvable by using goto. Will I goto hell if I use it? Disclaimer: This is not a programming question, it is a religious / philosophical one.
We are using Linux daily to UP our productivity - so UP yours!