Thread: How to exit from nested loops?

Originally Posted by frktons

Well, this is a good point. I assumed the limits are already
Actually I tested it and it takes about 1/3 second.

I was referring to your digit permutations of various lengths up to that large number. If you can get that to run in 1/3 seconds, we will all sing Kumbaya and dance around you.

Originally Posted by frktons

Or I could use a workaround:

Code:

for (x = 0; x < lim0; x++){
    for (x1 = 0; x1 < lim1; x1++){
         for (x2 = 0; x2 < lim2; x2++){
               if (contidion){
                   break_x1 = 1;
                   break_x = 1;
                   break; // this exit the inner loop only
                }
         }
         if (break_x1) break;
     }
      if (break_x) break;
}

Screw the extra flags, there's a much simpler way to exit nested loops that doesn't incur extra overhead for every loop iteration:

Code:

for (x = 0; x < lim0; x++) {
    for (x1 = 0; x1 < lim1; x1++) {
        for (x2 = 0; x2 < lim2; x2++) {
            if (condition) {
                x1 = lim1-1;
                x = lim0-1;
                break;
            }
        }
    }
}

It only adds overhead for when you actually want to break out (versus a goto).
I'm in favour of putting such a thing in its own function and using a return though.

As has become evident here though, just use a known correct function for building the strings. Even in the extremely unlikely case that the itoa function had a bug, it would be even more unlikely that it would be the same bug as other code. At the end of the day you have to look at how big your test is and make a judgement call as to whether it's easier to be sure that your test is correct with that huge thing you wrote, or with something smaller.
I'm really pleased that you're enthusiastically getting into unit tests. I am also, and built my own mini framework for it.

Originally Posted by claudiu

I was referring to your digit permutations of various lengths up to that large number. If you can get that to run in 1/3 seconds, we will all sing Kumbaya and dance around you.

Well! then start singing and dancing That is the time it takes.

Originally Posted by iMalc

Screw the extra flags, there's a much simpler way to exit nested loops that doesn't incur extra overhead for every loop iteration:

Code:

for (x = 0; x < lim0; x++) {
    for (x1 = 0; x1 < lim1; x1++) {
        for (x2 = 0; x2 < lim2; x2++) {
            if (condition) {
                x1 = lim1-1;
                x = lim0-1;
                break;
            }
        }
    }
}

It only adds overhead for when you actually want to break out (versus a goto).
I'm in favour of putting such a thing in its own function and using a return though.

As has become evident here though, just use a known correct function for building the strings. Even in the extremely unlikely case that the itoa function had a bug, it would be even more unlikely that it would be the same bug as other code. At the end of the day you have to look at how big your test is and make a judgement call as to whether it's easier to be sure that your test is correct with that huge thing you wrote, or with something smaller.
I'm really pleased that you're enthusiastically getting into unit tests. I am also, and built my own mini framework for it.

Yes, Malcom, It is something I used myself some time ago trying
to avoid the evil goto and fortunately it works just fine
with a small overhead.

The function/return solution is my preferite as well.

I'm glad you took the time to read some posts and comment them.
I really like your aptitude to code and dissect Algorithms

The code I wrote to generate the strings looks a little bit oversized
compared to the thing I'm trying to test. But it'll work just fine and
fast. Well it already does, but I'm adding something extra and I did
not get time enough to assemble, test and post it.

It'll come shortly. Only for those who care, please.

Originally Posted by frktons

Well! then start singing and dancing

Well, post the code here and then I will gladly.

Originally Posted by claudiu

Well, post the code here and then I will gladly.

Ok, I looked at the code I realized a week ago, and it is not 330 ms
as I recalled, but 3,330 ms on my machine. Probably on yours it 'll vary
depending on what compiler, system, CPU you are using.

I attach the routine, if you test it on your machine, please post the results
you get.

Ehhh... a few comments about your code.

Firstly, yes I have tested it on my travel Dell Mini 10v netbook which granted may disadvantage you, since it is lower in specs than your average desktop. I got about 17.6 seconds for the whole thing, which to be honest is not impressive by any means.

Secondly, you are falling in love with GOTO. Snap out of it! The main problem with using goto is that once you start using it, you think using it anywhere is fair game. It's not. While people advocate that it can be an optimum solution in some situations (and indeed it is), such cases should be extremely rare in your code. The rule of thumb is not to think whether you can use a goto, but think whether you can avoid it. If avoiding GOTO produces worse results, than you can go ahead and use it.... very sparingly though!