CodeGuru Home VC++ / MFC / C++ .NET / C# Visual Basic VB Forums
Results 1 to 10 of 10

Thread: to "goto" Or not to "goto"????

  1. #1
    Join Date
    Mar 2007

    to "goto" Or not to "goto"????

    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...


  2. #2
    Join Date
    Mar 2002
    St. Petersburg, Florida, USA

    Re: to "goto" Or not to "goto"????

    If you worked for me, and used a goto, you probably would not work for me much longer.

    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.


    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.
    TheCPUWizard is a registered trademark, all rights reserved. (If this post was helpful, please RATE it!)
    2008, 2009,2010
    In theory, there is no difference between theory and practice; in practice there is.

    * Join the fight, refuse to respond to posts that contain code outside of [code] ... [/code] tags. See here for instructions
    * How NOT to post a question here
    * Of course you read this carefully before you posted
    * Need homework help? Read this first

  3. #3
    Join Date
    Jul 2001
    Otaki, New Zealand

    Re: to "goto" Or not to "goto"????

    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.


  4. #4
    Join Date
    Apr 2007

    Re: to "goto" Or not to "goto"????

    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...

  5. #5
    Join Date
    Sep 2004

    Re: to "goto" Or not to "goto"????

    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!
    Computer Science/Engineering
    @ PSU
    Co-oping with IBM's zSeries team! wee

  6. #6
    Join Date
    Apr 2007

    Re: to "goto" Or not to "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

    ///Ask anybody, no really
    Last edited by Siddhartha; April 12th, 2007 at 06:50 AM.

  7. #7
    Join Date
    Nov 2006

    Re: to "goto" Or not to "goto"????

    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.

  8. #8
    Join Date
    Nov 2002

    Re: to "goto" Or not to "goto"????

    So much has been written about this topic, that it's ridiculous to ask the question again. Maybe you're trolling .....


  9. #9
    Join Date
    Feb 2007

    Re: to "goto" Or not to "goto"????

    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.

  10. #10
    Join Date
    Apr 1999
    Altrincham, England

    Re: to "goto" Or not to "goto"????

    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.
    Correct is better than fast. Simple is better than complex. Clear is better than cute. Safe is better than insecure.
    Sutter and Alexandrescu, C++ Coding Standards

    Programs must be written for people to read, and only incidentally for machines to execute.

    Harold Abelson and Gerald Jay Sussman

    The cheapest, fastest and most reliable components of a computer system are those that aren't there.
    -- Gordon Bell

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts

Windows Mobile Development Center

Click Here to Expand Forum to Full Width

On-Demand Webinars (sponsored)