Since goto is getting so popular these days....
-
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!
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!
-
I've heard some claim that it is valid if you're writing a state machine. Personally, I avoid goto like the plague!
WE ARE DYSLEXIC OF BORG. Refutance is systile. Your a$$ will be laminated. There are 10 kinds of people in the world: People who know binary and people who don't.
If you look at the state machine class that is automatically generated for a method that uses the C# yield return keyword, you will find goto statements. I think it would be brutally messy to implement otherwise.
-
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!
One-time-only, or occasional, use of 'goto will simply intensify the awareness of the Hell you are already in, but if used recursively, 'goto renders you fully aware of said Hell, and thus unable to reboot your consciousness. best, Bill
"Many : not conversant with mathematical studies, imagine that because it [the Analytical Engine] is to give results in numerical notation, its processes must consequently be arithmetical, numerical, rather than algebraical and analytical. This is an error. The engine can arrange and combine numerical quantities as if they were letters or any other general symbols; and it fact it might bring out its results in algebraical notation, were provisions made accordingly." Ada, Countess Lovelace, 1844
-
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).