Thread: FAQ: Someone know where to use "continue"

  1. #31
    Visionary Philosopher Sayeh's Avatar
    Join Date
    Aug 2002
    Posts
    212
    To All:

    Contrary to popular stupidity, there is nothing wrong with using goto or continue. both perform the same thing in assembler, a jump to an address.

    Normally, you don't need to use them. However, you cannot ever rule their use out 100%-- if you try, I'm sure you can find an example of logic that would require the use of each one, with no other way to do it.

    But it is incorrect to simply rule both statements out simply because you "feel" or some other fool told you that you shouldn't ever use them.

    Every tool in your toolbox has a purpose. Learn to use them all well, at the appropriate time. Only an amateur beats on a nail with pliers when the hammer is right there in the toolbox...

    Developing is all about being open-minded to conventional and non-conventional solutions. 'goto' and 'continue' are valid, C statements supported by all C/C++ compilers.
    It is not the spoon that bends, it is you who bends around the spoon.

  2. #32
    Confused Magos's Avatar
    Join Date
    Sep 2001
    Location
    Sweden
    Posts
    3,145
    Originally posted by Sayeh
    Every tool in your toolbox has a purpose. Learn to use them all well, at the appropriate time. Only an amateur beats on a nail with pliers when the hammer is right there in the toolbox...
    I agree, but can someone mention any good usage for goto?
    MagosX.com

    Give a man a fish and you feed him for a day.
    Teach a man to fish and you feed him for a lifetime.

  3. #33
    Registered User Vber's Avatar
    Join Date
    Nov 2002
    Posts
    807

    For goto, I didnt saw any usefull code..

    for continue, Salem gave a perfect example.
    I found a text talking about the goto statement:
    http://www.acm.org/classics/oct95/

    But again, if someone can give a nice example of using Goto, I'll be happy.

    Another think, if goto is good or not, I think that label's aren't so pretty to the program, it's make some confusion on the code, at least for me.

  4. #34
    Registered User Vber's Avatar
    Join Date
    Nov 2002
    Posts
    807

    I didn't told that I trusted on that document..

    I just read it to understand why he think that goto isn't so usefull.
    But still, I think that putting label in the code, isn't so pretty, in other words, this complicate a little bit my code, maybe because I'am new to C

  5. #35
    Registered User
    Join Date
    Oct 2002
    Posts
    46

    Talking

    [flame=on]
    very old debate. Dijkstra, Hoare, & Wirth trot this old nonsense out every few years. And It's spouted by academics who tire of teaching comp sci 101 students the art (yes art!) of programming. Which reqires clear thinking and a thorough knowlege of the tools at one's disposal not silly slogans like: "Goto considered harmful!", which stop thinking about your art.

    Think for yourselves & ask what is the clearest design of the algorithm that makes the best use of the resources at hand. I can't count the number of bad programs I've seen by profs (I work with academics) who "like to think in the abstract". Newbie cluelessness is usually a temporary condition, but only if you're willing to explore the forbidden zones of programming when the code starts to offend your artisan's sensibilities. I.e. learn enuf to know when to break the rules.

    Make no bones about it, both the "continue" & "break" statements are nothing but pretty-fied "goto"s. In c++ there are also the pretty-fied exceptions. As noted above, control structs like "if", "case", &c reduce to incuding them but they're oddly more removed from the debate.

    As for using a "goto" directly, well I've only been using c for a few months & only at the applications level. I haven't needed the "goto" statement yet and the "break" only a few times, but I use the "continue" often. However, at the systems level (Isn't c a systems language too?) I can't imagine what gnarled logic would ensue if I couldn't use a vector table now and then; these are even considered worse because they're indirect "goto"s.

    You don't need to use them often but when you do you really really need them. Or else you'll have to drop down to assembly.

  6. #36
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    Saw these examples, these doesn't show at all why to use continue.

    while (fgets(buf, sizeof(buf), fp) != NULL)
    {
    if (buf[0] == '#') continue;
    /* now go process the line */
    ...
    ...
    }
    Can be replaced by

    Code:
    while (fgets(buf, sizeof(buf), fp) != NULL)
    {
        if (buf[0] != '#')
        {
            /* now go process the line */
            ...
            ...
        }
    }
    Another example:

    #include <stdio.h>
    int main()
    {
    int x;
    for (x = 1; x <= 10; x++)
    {
    if (x == 5)
    continue;
    printf("%d ", x);
    }
    printf("Used continue to skip printing the value 5\n");
    return 0;
    }
    It can easily replaced by

    Code:
    #include <stdio.h>
    int main()
    {
        int x;
        for (x = 1; x <= 10; x++)
        {
             if (x != 5)
               printf("%d ", x);
        }
        printf("Used continue to skip printing the value 5\n");
        return 0;
    }
    Every tool in your toolbox has a purpose. Learn to use them all well, at the appropriate time. Only an amateur beats on a nail with pliers when the hammer is right there in the toolbox...
    It is okay to learn all tools in your toolbox, but you also must learn why to use certain tools and why not to use certain tools. Some tools may seem very usefull, but a bit more thought can show that there exists a "better" solution for which you don't need the tool. Note that I put better between "", in my opinion it is always possible to avoid things like goto and continue, just by adapting your logic, it sometimes requires a bit more thinking about your algorithm, but that's not bad.

    Anyway, I've seen lots of embedded systems passing by the last few years since I'm working and never seen goto or continue being used. So I don't think it is necessary to use, even in such time-critical and low-resource things like embedded systems.

  7. #37
    Registered User Vber's Avatar
    Join Date
    Nov 2002
    Posts
    807

    In yhe continue example..

    I don't see why not to use continue, instead opening another block.

  8. #38
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    Take a look at to following to code-fragments.

    Code:
    while (....)
    { 
        if (....) 
        { 
            ....
        } 
        else 
        { 
            ....
        } 
    } 
    
    while (....)
    { 
        if (....) 
        { 
            ....
            continue;
        } 
        
        ....
    }
    The first fragment is much better maintainable. It makes the logic more explicit and therefore also more readable which increases maintainability of your code.

    Another thing about the readability. If, in the second fragment, before the continue-statement there is a a large amount of code being placed. Then you have a large block after the if-statement and then after the if-block there can also be a block of code. If you just look at the code, it seems that if some condition is true, then the first block will be executed before the second block, but it isn't, because of the continue.

    When scanning to large amounts of code to check the structure of the code, you usually (also) use the identation, it gives a quick overview of the structure of code. When using continue in this situation, it would break up the structure and lead to an incorrect interpretation of the code its structure.

  9. #39
    Registered User moi's Avatar
    Join Date
    Jul 2002
    Posts
    946
    Originally posted by Shiro
    Saw these examples, these doesn't show at all why to use continue.



    Can be replaced by

    Code:
    while (fgets(buf, sizeof(buf), fp) != NULL)
    {
        if (buf[0] != '#')
        {
            /* now go process the line */
            ...
            ...
        }
    }
    so? all conditionals in C could be replaced by only if and goto if one wanted to. the continue version of this code is clearer and makes more sense than your version, simple as that.

    one thing btw i think java got right was the labeled loops and labeled break&continue, they replace almost all legitamant goto usages.
    hello, internet!

  10. #40
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    >the continue version of this code is clearer and makes more
    >sense than your version, simple as that.

    Well, that's your opinion. Mine is different, simple as that.

  11. #41
    Registered User
    Join Date
    Oct 2002
    Posts
    46
    When scanning to large amounts of code to check the structure of the code, you usually (also) use the identation, it gives a quick overview of the structure of code. When using continue in this situation, it would break up the structure and lead to an incorrect interpretation of the code its structure.
    It's a matter of opinion as to which is more readable. In the contrived examples given you don't see what can happen when you nest nest nest... ad nauseum. Over nesting also makes things very hard to read and thus difficult to maintain, defeating HLL too. I've seen this kinda junk where one makes a 4 page loop and no breaks and nests the "if"s with some going to the bottom and others closing in the middle of the loop. A common newbie structure, all so very structured & all so very unreadable.

    Anyway, I've seen lots of embedded systems passing by the last few years since I'm working and never seen goto or continue being used. So I don't think it is necessary to use, even in such time-critical and low-resource things like embedded systems.
    ?!... I'm quite skeptical that they run at all well. maybe you've got some really really smart compilers.

    You can recite poetry in Morse code too but...

  12. #42
    ....
    Join Date
    Aug 2001
    Location
    Groningen (NL)
    Posts
    2,380
    >It's a matter of opinion as to which is more readable.

    True.

    >Over nesting also makes things very hard to read and thus
    >difficult to maintain, defeating HLL too. I've seen this kinda junk
    >where one makes a 4 page loop and no breaks and nests
    >the "if"s with some going to the bottom and others closing in
    >the middle of the loop. A common newbie structure, all so very
    >structured & all so very unreadable.

    It is true that deep nesting makes things very hard to read. But this usually can be avoided by redesigning the algorithm.

    >?!... I'm quite skeptical that they run at all well. maybe you've
    >got some really really smart compilers.

    They run quite well, I didn't say they all run optimal, but they run well, without the use of things like continue or goto. The most important thing is designing an algorithm which is fast. The compiler is the second thing to look at.

    [edit]
    I'm very curious if someone can show me an example of an algorithm using continue which is faster than not using continue. I've never seen such, but it doesn't mean that it doesn't exist. So if someone knows such example, I'd be thankfull to learn from it.
    [/edit]
    Last edited by Shiro; 12-09-2002 at 02:39 PM.

  13. #43
    Registered User
    Join Date
    Oct 2002
    Posts
    46
    Originally posted by Shiro
    [The most important thing is designing an algorithm which is fast. The compiler is the second thing to look at. [/B]
    1) choose a good algorithm
    2) make the code work while keeping it readable/maintainable
    3) tune it by making it faster or smaller or whatever in the tight spots. One should consider this step all the time but apply it only sometimes and in limited areas. "Count your cycles where they count." But do count them.

    We're not that far apart. I'll bet we could read & maintain each other's code too.

  14. #44
    Blank
    Join Date
    Aug 2001
    Posts
    1,034
    Code:
    while (fgets(buf, sizeof(buf), fp) != NULL)
    {
    if (buf[0] == '#') continue;
    /* now go process the line */
    ...
    ...
    }
    This is a ok place to use it here mainly because it's a pretty popular idiom. It's also probably in the code to
    one of those functions such
    as scanf. Most of the time you might have something like

    Code:
    while (fgets(buf, sizeof(buf), fp) != NULL)
    {
         if (buf[0] == '#') 
               continue;
          
         if (buf[0] == ';')
               continue;
    
         // 50 lines of code that you don't want to indent
    }
    It is true that deep nesting makes things very hard to read. But this usually can be avoided by redesigning the algorithm.
    I don't think so, but most of the boring stuft like parsing where
    you might want to use continue can be done by a tool.

  15. #45
    ATH0 quzah's Avatar
    Join Date
    Oct 2001
    Posts
    14,826
    Originally posted by vVv
    [code]It's not hard to redesign proof-of-concept snippets. What would you do if further condition(s) occur while processing (i.e you can't add an ``&& other_condition'' to the first check), that render the rest of the code useless and require you to stop? Would you really want to make all that nested if-checks (which decreases readability), redesign that or simply use a quick continue? If you'd choose the second option, how would you do it?
    We aren't talking about self-modifying code here. Once compiled, your program is done. All checks are finished, unless it's a scriptible application, in which case, this whole point is moot anyway.

    As such, there is no scenario I can envision where your example would be valid. Furthremore, why couldn't I just add another && sitution?

    This isn't a holy war over the evils of continue. By all means, do whatever you want. Just make your code readable and clear so the next person that has to maintain your code knows what the hell is going on. That's the whole point.

    In everything you code, make sure the next idiot that follows you knows what's going on. Code as if an idiot is going to have to read your code after you're done with it.

    Quzah.
    Hope is the first step on the road to disappointment.

Popular pages Recent additions subscribe to a feed

Similar Threads

  1. Wiki FAQ
    By dwks in forum A Brief History of Cprogramming.com
    Replies: 192
    Last Post: 04-29-2008, 01:17 PM
  2. Help with FAQ
    By JoshG in forum Game Programming
    Replies: 19
    Last Post: 10-29-2002, 07:31 PM
  3. FAQ Check/Lock
    By RoD in forum A Brief History of Cprogramming.com
    Replies: 2
    Last Post: 10-15-2002, 11:21 AM