C++ labeled break?

This topic is 4272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

hi, i'm just wondering if there is an equivalent for this common Java command in C++. How to I break out of an outer level loop? eg. in java:
OuterLoop:
while(true)
{
//random code
while(true)
{
//random code
if(something)
break OuterLoop;
}
}


Share on other sites
The infinately abuseable goto command with a label after the loop is about as close as your going to get...

Share on other sites
There's no command for this that I know of in C++ but, you can achieve the same thing with something like this:

bool state = true;while ( state != false )     {        while ( true )            if ( blah... )              {               state = false;               break;              }      }

- xeddiex

Share on other sites
yes as eddie mentioned.
you can use Flags.

Share on other sites
Quote:
 Original post by CuppoJavahi,i'm just wondering if there is an equivalent for this common Java command in C++.How to I break out of an outer level loop?eg. in java:OuterLoop:while(true){ //random code while(true) { //random code if(something) break OuterLoop; }}

or depending on the situation, you can do this:
while(true){  //random code  while(true)  {    //random code    if(something){      break;    }    break;  }}

Share on other sites
Quote:
Original post by Tradone
Quote:
 Original post by CuppoJavahi,i'm just wondering if there is an equivalent for this common Java command in C++.How to I break out of an outer level loop?eg. in java:OuterLoop:while(true){ //random code while(true) { //random code if(something) break OuterLoop; }}

or depending on the situation, you can do this:
while(true){  //random code  while(true)  {    //random code    if(something){      break;    }    break;  }}

The second break will never be reached if you break above it.

Share on other sites
I didn't realize that was possible in Java. It seems a little strange, too, seeing as how it boasts of being safer than C++. breaks are restricted gotos, as they only take program flow in one directly, directly after the given loop. A labeled break is slightly more dangerous in that the # of loops broken can be greater than 1.

I guess I can add that to one of the few features I like about Java.

Share on other sites
Either hoist your inner loops into a separate function and use a return, or use a goto.

Building a scaffolding of flag-based breaks is clumsy.

Share on other sites
Thanks for the comments guys.
Yeah, the only suggestion that applied to my situation was the flag check solution.
Unfortunately, this is quite an intricate piece of code with four layers of loops, so flag checking would result in an unreadable mess, so I opted to pull my code into methods, using returns as a break substitute.

Thanks for the ideas guys.

Share on other sites
If I saw a programmer use cumbersome (and easily buggy) flags where a goto would be clearer, I would recommend changing to the goto in a code review. Really, "named breaks" is one of the cases where goto is usually better than the alternatives.

Share on other sites
Exceptions, anybody?

Share on other sites
Quote:
 Original post by CuppoJavahi,i'm just wondering if there is an equivalent for this common Java command in C++.How to I break out of an outer level loop?eg. in java:OuterLoop:while(true){ //random code while(true) { //random code if(something) break OuterLoop; }}
Sometimes you can handle the situation like this:
for (int i=0; i<n; ++i){    //Do some stuff    for (int j=0; j<m; ++j)    {        //Do more stuff        if(something)        {            i = n;            break;        }    }}
This is a little more efficient that using a "done" flag.
Also, given that both of the loops you show are "while (true)" loops, clearly they are not both infinite, so perhaps it would be better to structure them as "do .. while" loops or "for" loops etc anyway, in which case you could then use my suggestion.

Share on other sites
Quote:
 Original post by EasilyConfusedExceptions, anybody?

Exceptions are meant for error handling and not general program flow control. Vote +1 for goto.

Share on other sites
yeah like i say, its infinately abuseable, but is one of those cases where I would actually consider using it. If your careful it shouldn't cause a problem and perhaps in this case, it would lead to more efficient code than having to perform 4 checks with a bailout flag. Just be prepared to take some flack for using it from those who (in most cases rightly) think goto is spawn of satan.

Share on other sites
Exceptions are a tool like anything else and if local code is easier to understand and maintain and has less risk of resource leak by using them, I hardly see that the fact that this is not what they are "supposed" to be used for should push anyone towards thinking that goto was a "better" solution.

I have quite frequently used exceptions to represent normal termination conditions in code that otherwise would be far more complex, inextensible and hard to maintain otherwise.

[Ducks the inevitable flames approaching]...

Share on other sites
Or just refactor it a bit. Put the inner loop into a separate function, and let it return true/false/whatever you like when the outer loop should break.

Share on other sites
No reason you should be flamed. The only problem there is that, more than any other construct in the language, exceptions are slow. Horribly, terribly slow. Though they do beat out goto if you have class instances in nested scopes that need to be destroyed.

Share on other sites
Quote:
 Original post by EasilyConfusedI hardly see that the fact that this is not what they are "supposed" to be used for should push anyone towards thinking that goto was a "better" solution.I have quite frequently used exceptions to represent normal termination conditions in code that otherwise would be far more complex, inextensible and hard to maintain otherwise.

goto are used to go to a specific point in code.
exceptions are used for exceptional problems.
Wouldn't you say that what goto is supposed to be used for is better?

Did anyone even consider what Fruny said? Try doing something like this:
bool inner_loop(){    while( some_expression_two )    {        // Random code        if( some_expression_three )        {            return false;        }    }    return true;}void start_loop(){    while( some_expression && inner_loop() )    {        // Random code    }}

With most problems an approach like this is much better than having both loops in one function.

Share on other sites
Quote:
 Original post by SpoonbenderOr just refactor it a bit. Put the inner loop into a separate function, and let it return true/false/whatever you like when the outer loop should break.

Yeah, you should refactor that.

Quote:
 http://www.refactoring.com/catalog/removeControlFlag.htmlProblem: You have a variable that is acting as a control flag for a series of boolean expressions.Solution: Use a break or return instead.

Share on other sites
Quote:
 Exceptions are a tool like anything else and if local code is easier to understand and maintain and has less risk of resource leak by using them, I hardly see that the fact that this is not what they are "supposed" to be used for should push anyone towards thinking that goto was a "better" solution.I have quite frequently used exceptions to represent normal termination conditions in code that otherwise would be far more complex, inextensible and hard to maintain otherwise.

Don't. Please, just don't. This isn't just really bad practice, it's also an absolute killer on performance. People talk about performance penalties just for having exception handling in place, which can be significant, but the performance penalties for actually handling an exception are astronomical. Nobody cares, because you only throw an exception under exceptional circumstances, right?

Exceptions are a tool to be used, but it's also important to understand what makes a tool suitable for a certain job, and not for others. You don't use a sledgehammer to drive in a nail.

Share on other sites
Quote:
 Original post by Nemesis2k2You don't use a sledgehammer to drive in a nail.

Unless it is a really really big nail.

Sorry I'm bored. *ducks*

Share on other sites
Quote:
 Original post by KonfusiusYeah, you should refactor that.

Whatever
Quote:
 http://www.refactoring.com/catalog/introduceControlFlag.htmlProblem: Some wannabe programmer removed your cool control flag variables and replaced them with breaks or returns.Solution: Revert to an old version from CVS.

Share on other sites
Quote:
 Original post by CuppoJavaThanks for the comments guys.Yeah, the only suggestion that applied to my situation was the flag check solution.Unfortunately, this is quite an intricate piece of code with four layers of loops, so flag checking would result in an unreadable mess, so I opted to pull my code into methods, using returns as a break substitute.Thanks for the ideas guys.
What was wrong with goto? It's basically identical to Java's labelled break in this case, only the label mark is after the loop instead of before, and you use "goto X" instead of "break X".

Share on other sites
There is not too much inherently wrong with goto (although it does introduce an invisible constraint into your program whereby non-POD type variables cannot be declared, or any variable declared with an initializer, within the scope of the label and between the goto and the label), it just has extremely few legitimate uses. Most situations that people consider to be a good use of goto are, to my mind at least, situations sufficiently complex as to benefit from a refactoring that would, as a side-effect, eliminate the need for goto. A nested loop where an outer contains more than just the inner loop usually meets this critera.

Σnigma

Share on other sites
Nemesis' comment about the overhead of exceptions is entirely fair but surely there must come a point where code becomes so involved without them (passing up return conditions through loads of functions or repeatedly testing global variables) that this point becomes six of one, half dozen of the other?

Surely the whole point of exceptions was that existing (admittedly error-handling code primary) methods were actually producing more overhead than the exception mechanism?

I know there is some overhead involved with exception handling but from what little I have read about how assembly boffins can implement the mechanism, is it really THAT great?

I'd rather have clean and maintainable code that ran a trillionth of a second slower than code that was hard to read or modify, but then admittedly I'm not writing control code for a nuclear power plant.

Share on other sites

This topic is 4272 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

• Forum Statistics

• Total Topics
628714
• Total Posts
2984350

• 23
• 11
• 10
• 13
• 14