hi guys, i wonder if there is technically any difference between using break or return in order to quit a loop without reaching its condition?

You're talking about c++?
The answer is yes:
break will only break out of the 'most nested loop' . For example:

int main()
{
    for (int i = 0; i < 10; i++){
        for (int j = 0; j < 10; j++){
            if (j == 5) 
                break;
            std::cout << "inner=" << j <<"\n";
        }
        std::cout << "outer=" << i<<"\n";
    }
    return 0;
}

will print

inner=0
inner=1
inner=2
inner=3
inner=4
[B]outer=0[/B]
inner=0
inner=1
//etc etc etc

As you can see, the break statement only breaks the inner loop when it reaches 4 ( <5 ). Then it start all over because the outer loop isn't done yet.

If you replace the previous code with:

int main()
{
    for (int i = 0; i < 10; i++){
        for (int j = 0; j < 10; j++){
            if (j == 5) 
                return 0;
            std::cout << "j=" << j <<"\n";
        }
        std::cout << "i=" << i<<"\n";
    }
    return 0;
}

the code will print:

inner=0
inner=1
inner=2
inner=3
inner=4

And it's done. You've used return, which means that it should return from the current function. In this case the function is 'main' so it quits the program.

break; Just jumps, after an evalution. return(x); Will probably store the value were ever it feels appropriate, then tells the OS to return back to the called procedure.

> then tells the OS to return back to the called procedure.
The OS isn't involved in such things.

thanks nick, they will make the same effect if there is only one level of loop, not nested, as a conclusion..

thanks niek, they will make the same effect if there is only one level of loop, not nested, as a conclusion..

No. Break will jump out of a loop, return will jump out of a function. So only if your function exists out of only a loop, will they have they same effect.

No. Break will jump out of a loop, return will jump out of a function. So only if your function exists out of only a loop, will they have they same effect.

yeah that was what i wanted to say.

However, having multiple exit points for a function makes it difficult to maintain. There is a greater chance that you'll forget to do the clean ups (which will be usually at the end of the function).

>However, having multiple exit points for a function makes it difficult to maintain.
Forcing a single exit point where it doesn't make sense also makes the function difficult to maintain due to added unnatural complexity.

>There is a greater chance that you'll forget to do the clean ups
>(which will be usually at the end of the function).
In well designed code this isn't a problem. Most (if not all) of your "clean ups" should be handled in destructors anyway.

>However, having multiple exit points for a function makes it difficult to maintain.
Forcing a single exit point where it doesn't make sense also makes the function difficult to maintain due to added unnatural complexity.

>There is a greater chance that you'll forget to do the clean ups
>(which will be usually at the end of the function).
In well designed code this isn't a problem. Most (if not all) of your "clean ups" should be handled in destructors anyway.

Do you have destructor for a function to clean up the locals inside?

>Do you have destructor for a function to clean up the locals inside?
Functions don't have destructors, but you can get the same effect by wrapping resources that need to be cleaned up within a class. This is called RAII, and it's a key concept in good C++ design.

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.