Jump to content
  • Advertisement
Sign in to follow this  
UnshavenBastard

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.

If you intended to correct an error in the post then please contact us.

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


Link to post
Share on other sites
Advertisement
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 this post


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


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


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


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


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

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!