Printable View
ok i have one of those learn c++ books and in it the author states that a good programmer should never use the "goto" command, first of all is that the general consensus or do some of you guys use it? Cause it seems like it could be usefull but if its a bad habit i guess id rather not use it...
Thanx
If you worked for me, and used a goto, you probably would not work for me much longer. :D
Seriously, by the time you have written 250,000 lines of code [about 20 years at industry standard coding rate], you might have found 2 or 3 legitimate reasons.
Disclaimers:
1) In "straight" "C" there may be more cases. [i.e. not c++]
2) The above numbers do not necessarily apply to extreme real-time, embedded systems [like missle guidance] where saving 0.1uS may mean the difference between a successful program and an abject failure.
I have been programming for at least 25 years and in all that time I can honestly say I have never ever used a goto statement. I've always found a cleaner way.
If you were working for me and you used a 'goto' - I would be having serious words.
Regards
Alan
Oh my, there is a feature called 'search'. When you use this _very_ odd feature it might bring you to a thread called the 'goto' thread.
/That is all...
I'm not a pro programmer or anything like some of these guys but using goto is just wrong. Its even worse than global variables!
http://www.codeguru.com/forum/showth...highlight=goto
http://www.codeguru.com/forum/showth...highlight=goto
But, I feel for you.
/I apologize for the search bit. You should give thanks for that.
//Cause it's rare when I do that, apologize, I mean :D
///Ask anybody, no really :D
I read through the thread (from 2004) to see what's been said there.
The use of goto indicated by Linux kernel code is interesting.
Eluded to in both threads, one may be more likely to consider goto in C than in C++, though I've never used it myself.
Occasionally I'll dabble in assembler, especially if I need SSEx. There, jumps of all flavors are the only means of branching about the code outside of a call or an interrupt. All of them are goto's (relatively speaking).
Indeed, I'm sure the presence of the word in C is based on it's assembler roots, which brings me back to Linux kernel and the apparent presence of goto in that code. For writing an OS based on Unix, one is bound to think in terms of the assembler rather than in the higher level language notions of the application domain, so it's not surprising that people using C as an assembler would tend to think in those terms and reach for those commands.
Even then, however, I doubt the use of goto has actually saved any significant processing time. I think I've read, too, that the use of goto can limit the compilers ability to optimize code, so it's use would imply great care in observing that the results aren't unproductive.
As mentioned on the 2004 thread, there are constructs in C and C++ that represent a branch, conditional or otherwise. Break, the close bracket of an if, while, for or other block of code, switch - many of these explicitly represent one of the many jump mechanisms that otherwise would use goto.
Because of all of them, covering so many permutations for declaring the conditional execution of code, there really is no reason to use goto in the application domain.
The one classic case I was always given in support of goto was the quick exit from a nested loop (while, for, whatever kind). The idea was that within an inner loop, the goto could exit the loop faster, and it may be true to the tune of a few dozen nanoseconds in modern machines, perhaps a few microseconds in older hardware (pre-Pentium, for example).
For that matter, so would a return, assuming the loop was not some unrolled long section of code typical of non-structure programming.
Yet, with the additional, negligible speed comes the potential for bugs introduced from bypassing code that might need other kinds of 'release'. The unnoticed goto in the interior loop might skip some added code, from a subsequent extension, causing the need for a debugging session (a return can do that too, in the context of early termination from within the interior of a nested loop). When there's lots of goto's, and lots of labels, it can be difficult to follow - that's quite true of writing and debugging assembler.
Especially in C++, where the nested loop 'layers' might have objects on the stack, the goto might save nothing compared to the destructors involved.
Think of the layout of the switch and it's cases. This is an ordered and controlled use of a 'goto like' construct, which is more easily understood than otherwise uncontrolled use of goto, because it's just a list of conditionally execution statement blocks (or, more ideally, function calls - and for that there are often better C++ alternatives).
All of the conditional execution constructs were designed for readability and direct translation into assembler counterparts, and perhaps in the early phase of C's development the designers felt a 'goto' was just expedient - and it stuck. Eventually, the remaining map of required language development representing conditional execution of code was so complete, the old word became redundant, but with some fans and their reasons.
So much has been written about this topic, that it's ridiculous to ask the question again. Maybe you're trolling .....
Mike
Its pretty safe to say there really are very few reasons you should ever use a goto. That being said gotos are very fast, and there is nothing wrong with using them. Gotos are just a jump to a label in assembly so if you think they are messy try debugging a 20,000 line assembly program and you might not mind them so much.
Yep. I avoid goto, since it breaks the block structuring of the program. And I also class "continue" and "break" (except in switch statements - which I also try to avoid) as gotos.
For those who are wondering - I don't like switches and will try to come up with a design in which I always know which "case" is appropriate - for example, State Pattern does a good job of eliminating switches. Of course, I'm not going to break my back doing it, and there are cases where a simple switch works, but I try to avoid it if I can - it makes thing so much cleaner.