Sign in to follow this  
CuppoJava

C++ labeled break?

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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by CuppoJava
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;
}
}

or depending on the situation, you can do this:


while(true)
{
//random code
while(true)
{
//random code
if(something){
break;
}
break;
}
}

Share this post


Link to post
Share on other sites
Quote:
Original post by Tradone
Quote:
Original post by CuppoJava
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;
}
}

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by CuppoJava
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;
}
}
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 this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by EasilyConfused
Exceptions, anybody?


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

Share this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Quote:
Original post by EasilyConfused
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.

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 this post


Link to post
Share on other sites
Quote:
Original post by Spoonbender
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.


Yeah, you should refactor that.

Quote:

http://www.refactoring.com/catalog/removeControlFlag.html

Problem: 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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by Konfusius
Yeah, you should refactor that.

Whatever
Quote:

http://www.refactoring.com/catalog/introduceControlFlag.html

Problem: 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 this post


Link to post
Share on other sites
Guest Anonymous Poster
Quote:
Original post by CuppoJava
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.
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
Share on other sites

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

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this