# will return in a loop corrupt stack?

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

## Recommended Posts

(If there are differences, I'm interested in specific answers concerning C, C++, C#, Pascal ... ) Hi, I often stumbled upon comments in source codes like "unwind stack"(lamothe) when ie. setting a bool variable to true and break-ing out of a loop instead of just return true;-ing out of the loop:
bool foo()
{
bool b=false;

for (int i=0; i<10; ++i)
{
if (i==5)
{ b=true;
break;
}
}

return b;
}

// as opposed to:

bool bar()
{
for (int i=0; i<10; ++i)
{
if (i==5)
return true;
}

return false;
}


Will the latter corrupt the stack in some languages/implementations, or is this guaranteed to work flawlessly everywere? On the one hand, I think allowing such bad things to happen would be silly of language implementers, on the other hand I always had a bad feeling (long before I read such comments) about not "bringing things into the original state" if you know what I mean, and always did and still do it the way like the foo() function is implemented, intiuitively.
@ Mods: The message preview seems to have bugs, my (C, C++, C# was always depicted as (C, C, C#

##### Share on other sites
No, C++ compilers should just jmp to the end of the function, destroy local objects, unwind the stack and ret correctly.

##### Share on other sites
How could that possibly corrupt the stack? It's not like every single construct used its own. A loop runs in the same context as the function it's it, and returning from inside that function can easily "unwind" the stack, no matter where the return is (the stack itself is only defined by a base pointer). However, there apparently are people who think that there should only be exactly one "return" per function, and that it should be at the end.

##### Share on other sites
Quote:
 Original post by ShadowdancerHowever, there apparently are people who think that there should only be exactly one "return" per function, and that it should be at the end.

Which is a bit dumb considering you have to use a break; to get out of the loop - but oh no, they don't like break; either, so you have to re-arrange the whole loop. Anyway, off topic.

In the first case you add an extra variable and thus needlessly complicate the logic, in my opinion.

Sigh.

##### Share on other sites
for something like this:

for( int i = 0; i < BLAHMOO; i++ ){     if( m_Something.id == i )     {          return true;     }}return false;

Just returning instead of setting a variable then returning that variable is great. Some times you may want to set data based on that loop, break out, then do something afterwards with it though, so you would not just return.

int id = -1;for( int i = 0; i < Blah; i++){     if( Moo.id == i )     {          id = i;          break;     }}     if( id == -1 )          return false;     //otherwise     DoSomethingBasedOnTheID( id );     return true;

This may not answer your question directly, but those are the different scenerios where you would use one over the other.

Returning out of a function in a loop won't affect anything... may even cause a significant speed increase depending on the frequency its called and length of the loop.

Think of return b as "Go back to the function you came from, and bring B with you because that function is waiting for it."

So saying that anywhere in the function won't make a difference to your program. The only thing it will affect is how much of the function it does and the value of your return.

Hope I helped.

##### Share on other sites
also, everytime you return no matter where you return from it will take care of the stack and everything just the same.

##### Share on other sites
thanks ;)

I just again saw through some old source where it was done this way,
and I thought I just ask other people whether there might be a sound reason.
So, there isn't, fine :-)

##### Share on other sites
Infact, there is a reasonably sound reason, although possibly not so much with POD types, and that reason is "Named Return Value Optimization".

##### Share on other sites
RVO and NRVO shouldn't be affected by the number and placement of your return statements.

##### Share on other sites
yes, I probably should have made that clear and stuff... i'm sorry Fruny, dont hurt me [sad]

1. 1
2. 2
Rutin
25
3. 3
4. 4
JoeJ
18
5. 5
gaxio
11

• 14
• 22
• 11
• 11
• 9
• ### Forum Statistics

• Total Topics
631766
• Total Posts
3002215
×