Printable View
Hello, I'm wondering if the use of goto is so wrong as some people say: I understand that this is to avoid the "spaghetti" problem ( I remember some "outstanding" C64 program... ) but used with wishdom I think it's a good possibility.
For example, I can use it to jump directly to a common exit part of a function from any place in the function where I catch an error...
BrownB
Oh yes, another curiosity: how does the "rating" work in these forums?
search the boards for both of those answers then ask again
Structure your program correctly and there is no need for a goto statement.
goto is fine if used carefully. A good time for goto is common error handling code or leaving a deeply nested loop. Programs with need for performance can use goto too. While goto can be replaced with better control structures and performance is okay without it and goto does not make the code simpler, it should be avoided.
The sample framework that came with the old DirectX SDK used to have a goto statement inside of the EnumerateDevices function. I've been looking at the updated code and it seems that the goto has since been removed.
I hear people get fired for using goto on a team effort project. lol.
I have seen a single useful goto in about 6 years of everyday professional coding. No, it's not totally useless, only in 99.99% of the cases. As a rule of thumb, if you see one, it's wrong.
Let's say you find a situation in which using goto is the better option. There would be more problems to using the goto and being criticized for it, than for using the alternatives and having a less effective solution.
» The goto statement was once widely used. Unfortunately code that used goto extensively was poorly structured and could easily become unmanageable, and is known as "spaghetti code". Today, programming languages provide other ways to structure code so goto is rarely needed. In C++ it is always possible to use something other than goto to achieve what you need.Quote:
Originally Posted by BrownB
Note that the use of goto is a religious issue and has provoked a great deal of debate. In C++ there is always a better alternative for writing loops, so you don't need to use goto at all. There are other circumstances where goto may be more appropriate than the alternatives, though that is a seperate subject.
» Like previously stated, there is always a better alternative to the goto statement. Keep in mind when you use it to exit a block which contains aggregates requiring destructors, the destructors will run before the goto transfers control. The compiler still forbids using goto to enter a scope that requires constructors.Quote:
Originally Posted by BrownB
The indiscriminate use of goto statements has caused tangled, miserable, impossible-to-read programs. To avoid the use of goto, more sophisticated, tightly controlled looping commands have been introduced: for, while, and do-while. Using these makes programs more easily understood, and goto is generally avoided, but one might argue that the case has been a bit overstated. Like any tool, carefully used and in the right hands, goto can be a useful construct, and the ANSI committee decided to keep it in the language because it has its legitimate uses.
» Some feel that the reputation aspect is not much more than just a fun little addition. It has nothing to do with your real status on the board. It's just for readers to see how reliable your response is.Quote:
Originally Posted by BrownB
The Reputation System is not something I would stress over.
- Stack Overflow
Psst, Stack: We're on the C board here. No C++, deconstructors, etc. ;)
I know,
It's best I give the whole explanation than just half of it. :cool:
- Stack Overflow
does anyone see anything wrong with this code?
Code:void main(char **c, int i)
{
int x;
if(x)
x = 0;
else
goto label;
label:
__asm mov eax, x
}
You mean besides the bassackwards main() definition? Or were you just referring to the sheer uselessness of the entire program?
uh, the bassackwardsness
Thank you all for your replies on this basic "quasi-philosophic" question. My point of view is this: I think that a program structure should be set as a study before coding, and so the goto statement / tecnique is just a tool, not a structure choice: the compiled asm code has many jmps, and it's well structured. Aren't jmps logically the same as gotos? (I'm speaking about C programming => no unknown contructor/destructor invoking precedence )
The problem is in the maintenance / upgrade of the code, I agree. But what about the situation below:
I think this isn't problematic, and it's clearer and easier to maintain than repeating a "database close" and returning on each error catched.Code:- opening a database; error on open? goto Error
- reading database ( so database is open ); error on Read? goto ErrorClose;
- working with data; on error goto ErrorClose;
- writing data; on error goto ErrorClose;
ErrorClose:
Close database file;
Error:
return errorCode;
If I'm in error (my degree isn't in Information Technology ) I beg your pardon ;)
BrownB
You could do something as in this piece of pseudo-code:Quote:
Originally Posted by BrownB
It's up to you whether or not you prefer it this way. Other languages like C#, Java or Delphi/Pascal offer exception handling for this situation. I'm not sure about C++, but I think it does, too.Code:err= open(database);
if (!err) {
err= read(database);
if (!err) {
err= dosomething(database);
if (!err)
err= write(database);
}
close(database);
}
if (err)
printf("error %i while %s\n", err, getdesc(err));
How about
More often than not, the sudden urge to use goto is a sign of poor design - for example digging your way out of a large function which should have been split into several smaller functions long ago.Code:if ( open_database() ) {
if ( read_database() ) {
// do stuff
} else {
// error reading database
}
// close database
} else {
// error opening database
}
If your functions are small and have a clearly defined purpose, then there shouldn't be a need for goto.
A massive rambling function trying to do too much all but makes goto a necessity, but the real fix is to redesign it.
> it's clearer and easier to maintain than repeating a "database close"
Well I usually think in terms of matched pairs of functions, something along the lines of
The success (or otherwise) of do_stuff() doesn't matter to this bit of code, the file is opened in exactly one place, and closed in exactly one place.Code:FILE *fp = fopen( "file", "r" );
if ( fp != NULL ) {
do_stuff( fp );
fclose( fp );
} else {
// open error
}
I try to stay with the principle of one entry, one exit when possible. However there are times when an early out in a function is desirable such as in a recursive function or a function for graphics where the early out means higher framerates.
I haven't used GOTO since GW BASIC version 1.0.
The only exception to this is in BASIC's ON ERROR GOTO or ON LOCAL ERROR GOTO. Unfortunately VB 6 didn't find a better way to deal with error handling so they resorted to the goto which is just hideous.
I think there is another aspect to this debate though. You may actually be working against your compiler when you use a goto here or there. Loops look a lot different in assembler and often times they must short jump to a label which is identical really to a goto. So in theory your goto may actually be ignored by the compiler if it deems that it has already taken care of the goto with its own jump in the code.
Which brings us back to Salem's point. If you ever find yourself in a situation where you REALLY MUST USE A GOTO, then redesign your code.Quote:
So in theory your goto may actually be ignored by the compiler if it deems that it has already taken care of the goto with its own jump in the code.
I know someone whos DIOS language compiler (with over 200,000 lines of code) uses goto as his main loop function. He can update and modify his program with speed and efficiancy without any errors at all. He even made his own keyword that uses a complicated branch-goto thing. I don't know why anyone other than him would want to read his compilers code, so it doesn't matter what he uses.
Yeah which is what I said about 20,000,000,000,000 goto threads ago. Why do we keep responding to these goto threads?Quote:
Which brings us back to Salem's point. If you ever find yourself in a situation where you REALLY MUST USE A GOTO, then redesign your code.
Anything controversial makes for good reading. ;) Also posters change, so you tend to get a different slant each time. :DQuote:
Originally Posted by Bubba
I hadn't really ever thought about it, just assumed from previous threads that goto does have the occasional use. But Salem makes a good point, if you structure your code properly, it's necessity may evaporate.
Mmmm... perhaps I'm wrong, but I think that anyone who is bored from a thread, could just let it as it is: I called this "not important", so Bubba, please don't feel bad with me: Googling and seraching is ok, but I love so much speaking!!Quote:
Originally Posted by Bubba
Who doesn't care about this question, well...it's not critical!;)
Merry Christmas and goto next year!:)
BrownB
The goto isn't really neccessary here. Next year will be reached in any case, unless maybe somebody calls die() first.Quote:
Originally Posted by BrownB
THIS is the real wish I made...;)Quote:
Originally Posted by Nyda
Bye!
I think year() is called recursively
Yeah, the stack is collapsed when you die, and you end up back at top level !
Though some in some languages your code is sent to the debugger, and then becomes a tsr (terminate and stay resident) program.
However, some times when a process fails to die properly, or when something else goes askew, it ends up a zombie.
Quzah.
And then it's child windows have to put it in safe mode...
I just came back from Christmas "holidays"...and found my square RED?! Wow: I just understood how votation works..:D
And also I finally undestood the goto problem:
- never SAY this word with programmers: they could think you're a chicken well dressed..
- never WRITE this word in any piece code... don't #define it in another way, coward!
- never THINK this word: it may take your reasoning into unpredictable states..!
At this time...I don't remember what we're speaking about!! This should be good enough to bring my points up and restore the green square...;)
Bye!
>And also I finally undestood the goto problem:
There is no goto problem. Use it when it's the best option, otherwise don't.
>- never SAY this word with programmers:
This only applies to ignorant programmers.
>- never WRITE this word in any piece code...
This only applies if you're posting code to a forum or newsgroup. For real programs the conventional motto is: Your code, your rules, and everyone else can butt out.
>- never THINK this word:
Don't listen to people like that, it's bad for your mental health.
In fact I found a use for it this morning. I was in a heavily nested loop and just used to break out of it when a certain condition could not be fulfilled.
Why were you in a heavily nested loop to begin with? This is one of the valid uses for goto, but it's also one of the easier ones to replace through a function call. People who read your code will thank you for it too. The more layers of nesting a reader has to go through, the less they'll understand the logic.
The good folks that developed glibc even used it ;)
Found this when playing with that strstr() post last week:
http://gehenna.pell.portland.or.us/~...strstr.c.glibc
Parsing HTTP Headers. I've gotta keep reading in chars, to keep reading in header values, to keep reading in headers, until I reach a blank line signifying the beginning of HTTP content. And there are certain characters I can encounter which mean that the HTTP request is invalid - so I need to break out of the loop.Quote:
Why were you in a heavily nested loop to begin with?