C++ labeled break?
Quote:Original post by CuppoJavaSometimes you can handle the situation like this:
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; }}
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; } }}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.
Quote:Original post by EasilyConfused
Exceptions, anybody?
Exceptions are meant for error handling and not general program flow control. Vote +1 for goto.
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.
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]...
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]...
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.
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.
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.
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.
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.
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
