FAQ: Someone know where to use "continue"

[Vber]

in a usefull way? I dont see any useful charge to the continue command. You guys got a useful code with Continue?

In other words, why to use continue? :)

[Shiro]

In my opinion, it is usually better to avoid such statements like continue or goto. Avoiding these statements leads in general to more structured code and forces you to design a structured algorithm without statements which make the program jump through the code.

So, no, I don't see a usefull way to use continue.

[Vber]

I wont use continue and goto :)

[Magos]

Is continue really that bad? I've never really used it, but I can't see how it can screw things up like goto can.

[Mister C]

You can eliminate any continue-using an if

You can use continue to write clever code!!

[Polymorphic OOP]

Using continue is not bad. Goto is bad! Continue doesn't screw with the general flow of the program like a goto does.

[moi]

continue is good :)

[Vber]

I didn't saw any *real* good example for continue..
it's not a bad thing, right. but not so usefull too right? :)

[Hammer]

>>it's not a bad thing, right.
Right, it's not a bad thing.

>>but not so usefull too right?
Wrong, all valid statements are useful in their rightful places. Here's an example that reads input from a FILE* processing only the lines that don't start with a # (comment marker in some shells): (same layout as vVv's)

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

[Mister C]

Here is an example I use to show my students: from C How to Program

continue- used to alter flow of control


#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;
}



Result : 1 2 3 4 6 7 8 9 10
Used continue to skip printing the value 5

[beely]

Originally posted by Magos
Is continue really that bad? I've never really used it, but I can't see how it can screw things up like goto can.

refer to the structure / flowchart, is there any "CONTINUE" in the program?? i dont think that continue should be good in program structure. just one statements .. goto, continue, break (except for switch usage) is not recommended in program. this is BAD program. try to avoid using the continue anyway.

-- beely

[Polymorphic OOP]

Originally posted by beely
.. goto, continue, break (except for switch usage) is not recommended in program. this is BAD program. try to avoid using the continue anyway.

continue and break don't mess with the flow of the program in the way that goto does. goto is naughty, but continue and break are still your friends. If anything, switch statements are more "bad practice" than break. While continue statements can often times be avoided (though often times they shouldn't be because it often times makes "more logical sense" to use a continue depending on what you'd want to accomplish), break often times can't be avoided (unless you use return) because many times you need to break out of a loop after part of the body has been executed for that particular iteration.

[master5001]

Along with what Polymorphic OOP is saying, break is often time under used. For example lets look at a for loop that scans an array for a value:



int i, contains_value = 0;

for(i = 0; i < sizeof(array); i++)
if(array[i] == target_value) {
contains_value = 1;
break;
}



Without the break statement the whole array would continue to look for the target_value even after it found it. Continue can also add a level of optimization analogous to this. Even goto's have their place (that doesn't mean I embrace them).

[beely]

int i, contains_value = 0;

for(i = 0; i < sizeof(array); i++)
if(array[i] == target_value) {
contains_value = 1;
break;
}


according to your code. it's bad programming althoug it's working. why not try this ??


int i, contains_value = 0;
int error = 0;

for(i = 0; i < sizeof(array) && error == 0 ; i++)
if(array[i] == target_value) {
contains_value = 1;
error = 1;
}
--i; // replace back to the value if you wish.


so, decide whether which program is better. for me , i would choose my code. as i said, break OR continue in the for-statement is bad structure. have you seen break or continue in flowchart??? no .. is it??? then why should put for break & continue.

[beely]

Originally posted by Polymorphic OOP
..., switch statements are more "bad practice" than break. While continue statements can often times be avoided (though often .....

well.... just for comment. switch may use it at anytime. it's not bad practice, and the usage of switch is better than using nested if-statement. switch-statement could found in the flowchart, and it's consider a good structure too!

[Polymorphic OOP]

Why the heck do you keep saying THE flow chart. What the heck are you talking about?

[beely]

sorry for the error, the code should be this ...

int i, contains_value = 0;
int error = 0;

for(i = 0; i < sizeof(array) && error == 0 ; i++)
if(array[i] == target_value) {
contains_value = 1;
error = 1;
}

[master5001]

I was going to make a joke about the flow chart thing but you replied too fast :(

Anyways, the two samples of code are functionally identical and both fairly optimized. But many times I don't happen to have the variable error handy. I never add variable when I don't need to. Our code is identical, only mine uses one less variable.

[Polymorphic OOP]

Why? because your version introduces an entire new variable that has to be compared every single time it loops. A break handles the situation fine and doesn't mess with the flow in the manner that a goto does. Your version requires more space on the stack and adds a comparison on every iteration. Using a break doesn't introduce anything else.

[beely]

hmm, a bit question,
is the program better refer what's shown on flowchart ?
if it's true, then goto, continue, and break is not recommended replace at the certain program.

master5001, any comment on flowchart question ?

[beely]

so how's the "break" statement on the flowchart look like ??

[beely]

Originally posted by master5001
I was going to make a joke about the flow chart thing but you replied too fast :(

Anyways, the two samples of code are functionally identical and both fairly optimized. But many times I don't happen to have the variable error handy. I never add variable when I don't need to. Our code is identical, only mine uses one less variable.

:rolleyes: did you read a book called "C how to program" by deitel...

so, their comment said that goto, break, and continue, most of programmer didn't use them ..... bla bla bla ....

as a programmer, should they follow on the flowchart???

[master5001]

Hmmm, now here is something that is very interesting. I wrote a quick program that tested the two loops it turns out that mine (the one with a break statement) was better optimized by the compiler since it took 9 seconds to go through an array 16777215 times whereas, yours took 27 seconds. That was with full optimizations turned on.

[Polymorphic OOP]

Of course it took longer! Without the break he added an entire extra check on every single loop!

[beely]

so ?? without "break" . it's also can use other way. for eg:

for (i = 0 ; i<= MAX && end== 0 ; i++)
{
...
...
if (...){
..
..
end = 1;
}

so....?

[master5001]

Well beely, I tried code that looked something like:



int i, contains_value = 0;
int error = 0;
size_t size;

for(size = sizeof(array);size-- && !contains_value;)
if(array[array_size] == target_value)
contains_value = 1;




And it inlined it (of course to keep things even I inlined mine as well) and the results are 15 secons for your method and 7 for mine. Sorry, but break, continue, and goto have their place in this universe. The bottom line is that your compiler understands that it needs to optimize a loop a certain way when a break or continue is present. It won't necessarily give a loop that doesn't contain a break as much care in terms of optimization. Also, as Polymorphic said, you have an additional operation that I don't.

[beely]

hmm... i guess i'm better use on my way. everyone will have a lot of way to do the program. as i said, as a good programmer, he /she would follow on the flowchart. goto, continue & break is not recommended to use. but if feel that need to use it, it' okay, but not recommended. yeah, master5001, i got your point. but if you are using break statement, this is not a good sturture in program (for me). but i would another variable the control the loop-statement. anyway, you did find out alot of situation where they did talk about goto, continue & break on the previous threads. but what's the conclusion? they did say that it's bad structure.... bla bla bla. dependent on you which one you prefer.
just one statement, goto, continue & break is not found in flowchart. and if yes, how to flowchart look like? if found out the flowchart look like, this might be unstructure / untidy structure. anyway, dependent on what type want to use ... or you may find out most of the refer book should tell about the comment that i said.

-- beely

[beely]

Originally posted by master5001
Well beely, I tried code that looked something like:



int i, contains_value = 0;
int error = 0;
size_t size;

for(size = sizeof(array);size-- && !contains_value;)
if(array[array_size] == target_value)
contains_value = 1;




And it inlined it (of course to keep things even I inlined mine as well) and the results are 15 secons for your method and 7 for mine. Sorry, but break, continue, and goto have their place in this universe. The bottom line is that your compiler understands that it needs to optimize a loop a certain way when a break or continue is present. It won't necessarily give a loop that doesn't contain a break as much care in terms of optimization. Also, as Polymorphic said, you have an additional operation that I don't.

hmm... may you are right. but i still thinking the break won use it for my whole life (if necessary) on my program

[fou]

Originally posted by beely

int i, contains_value = 0;

for(i = 0; i < sizeof(array); i++)
if(array[i] == target_value) {
contains_value = 1;
break;
}


according to your code. it's bad programming althoug it's working. why not try this ??


int i, contains_value = 0;
int error = 0;

for(i = 0; i < sizeof(array) && error == 0 ; i++)
if(array[i] == target_value) {
contains_value = 1;
error = 1;
}
--i; // replace back to the value if you wish.


so, decide whether which program is better. for me , i would choose my code. as i said, break OR continue in the for-statement is bad structure. have you seen break or continue in flowchart??? no .. is it??? then why should put for break & continue.

Your code requires an extra compare for each iteration of the loop as well as being less easy to read. If you are reading a couple of million characters (MB) or tens of millions this is a big waste just to avoid a simple break statement. I also use continue as using multiple ifs gets so complicated and so many tabs it's not worth it. Continue is also easier to read.

[master5001]

Hmmm. In my program I added a loop that uses a continue statement and one that uses a goto's. Here are the results:

use condition: 10 seconds
use break: 4 seconds
use continue: 8 seconds
use goto: 0 seconds

It is only fitting that a goto statement would be broken during my test :) The goto thing would not work properly because I believe the compiler optimized it out.

[Sayeh]

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.

[Magos]

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? :)

[Vber]

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.

[Vber]

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 :)

[rafe]

[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 :eek: :eek: 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.

[Shiro]

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


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


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

[Vber]

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

[Shiro]

Take a look at to following to code-fragments.


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.

[moi]

Originally posted by Shiro
Saw these examples, these doesn't show at all why to use continue.



Can be replaced by


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.

[Shiro]

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

[rafe]

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

[Shiro]

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


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.

[rafe]

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. :cool: I'll bet we could read & maintain each other's code too.

[Nick]

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


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.

[quzah]

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.

[master5001]

Originally posted by Shiro

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.


As I said before, in my tests continue beats out not using continue. For those who are interested here is the code I used during my last test.

[quzah]

For an accurate test, you really should use identical loops. Furthermore, you need to make sure in each case you end up testing for the same exact thing. Without it, the test is hardly accurate. IE: Just because you write code to use the word 'continue' doesn't mean you're using the same number of checks.


To reply to the above post, no, it wasn't directly specificly at you. It was more of an "in general" observation of these types of threads. They in the just end up as threads where one person argues their point, another argues theirs, and neither one will ever convince the other because in some situations, there is no real "right way". That's mainly what that comment was about.


Quzah.

[quzah]

Originally posted by vVv
Personally, I can't remember the last time I used nested ``continue'''s or even a single ``goto'' - yet I don't think they should be avoided by all costs.
And that's my entire point.

As for the comment regarding checks, if you look at the provided code, you'll notice that the "for" loops are different on two or three of the checks. Additionally, they end up checking for different values.

If you're trying to compare one method versus another, your tests should be as near identical as possible. That's the point. (Look at the attached .c file, you'll see what I'm talking about.) It's unfair to compare tests if the tests themselves do not have the same standards or criteria.

Quzah.

[master5001]

Preach on Quzah! And that is the bottom line. My tests merely show that using continue is faster sometimes, but a program doesn't always call for it. Also, there are a number of other optimizations that can be made before using break or continue. My point was not to show that you need to use break to make a fast loop, rather, my point was to show an example of where a break statement is best.

[beely]

Originally posted by Magos
I agree, but can someone mention any good usage for goto? :)

goto is very dangerous in programming structure. this could make your programming more confusing.... just like looping there and looping here... and then going there and then going here... it's not recommended to use it anyway.