Function calls

[totalwar235]

this questions may be vague, but how many functions can you open up through function calls without ending the function. and example would be...

int FunctionOne();
int FunctionTwo();
int FunctionThree();
int FunctionFour();
int FunctionFive();

int main()
{
   FunctionOne();

   return 0;
}

int FunctionOne()
{
  FunctionTwo;

  return 0;
}

int FunctionTwo()
{
  FunctionThree;

  return 0;
} //ect...

what i am asking is how many times should you be able to do this before the program does not run the next function.

*using visual C++ 2008 EE
*i have the same problem but my real code is 12 pages long if printed and has 5 functions runnning

[mrnutty]

What you showed above is almost like recursion :

void func(long i){
  if(i > 0)
   func(i - 1);
}

Say "i = 5", then the functin func() will be called 6 times, because of the initial called. So your question is directly related to the question, "whats the highest value of i" assuming no overflow.

The answer to your question is, that it depends. It depends on the memory. You can call a function in another function in another function ...and so on, as long as the memory allows it to. Otherwise there is be a overflow in memory of stack.

Also worth noting, the code you posted above doesn't actually call FunctionTwo, or FunctionThree. I'm guessing this was a typo. But the idea is that each function call pushes new variables onto the stack, and when the function returns - either when it is explicitly stated, or implicitly stated at the end of the function - it releases all the memory those variables occupied (the exception being static variables). So the catch with nesting functions like that is that it pushes variables onto the stack, but doesn't release them. That's why recursion is generally considered a bad idea, at least without appropriate safety nets, such as the if statement in firstPerson's example.

All things considered, you ought to to be fine with five functions nested like that. However, if you can, I'd avoid doing that design entirely. Like instead of nesting the next function call in the current function, you could easily call each function in order in main() and get the same results without any risk of overflowing the stack.

[Duki]

@embooglement: Unless the o/p has an application that requires this type of encapsulation or abstraction - in which case, simply calling from main() won't work.

@o/p: I wouldn't avoid this type of design for the sake of preserving your stack, assuming it's because you're trying to maintain OOD. You'll see as you begin in a real-work environment, this is extremely common with larger applications. I work with software that sometimes has nested well over 10 functions before returning up the stack. If it helps you maintain a good design, and it's not a ridiculous number of function calls, don't worry about it.

Another point worth noting is the number of allowed function calls depends on the function and it's variables. Larger functions with large numbers of variables will decrease your stack much quicker than a simple 4-5 line method.

@Duki: I wasn't saying that it's necessarily a bad design, I was just saying that in the case of the example code he gave there was another way of doing it where stack overflow wouldn't be a concern. Ultimately it depends on what your doing, all I was getting at is to not trap yourself in a design that could become problematic when there might be an equally easy but safer way of doing it.

[totalwar235]

@embooglement: ya they were typo's. i had to do that example quickly, i was in the middle of class, also, i do not really know many other ways to do it because i only took 1 semester of it in high school and i have read most of a beginner's book.

@Duki: i think the problem is with all my variables stacking on top of each other since i have 150+ lines of code in each function.

[totalwar235]

@embooglement: ya they were typo's. i had to do that example quickly, i was in the middle of class, also, i do not really know many other ways to do it because i only took 1 semester of it in high school and i have read most of a beginner's book.

@Duki: i think the problem is with all my variables stacking on top of each other since i have 150+ lines of code in each function.

i forgot to add, if i cannot cut down on my functions, is there some kind of way to expand the amount of ram i can use compiling so it can work? or an easy way to compress a vector.

(for some reason it won't let me edit my last post :\ )

Well, the other thing you could do is try to break up each function into smaller functions, that way each one isn't so large, and the stack gets freed up a little more often.

[Duki]

I agree with embooglement. You functions should rarely (if ever) be that large. The general rule I go by is, if it takes more than a sentence or two to describe the function, it's too long and should be broken up. This also plays along with OOD in that, you want your code to be extensible and reusable. Creating many smaller functions rather than a few large functions increases the probability that you'll be able to use those functions later for something else.

Example: Instead of writing one large function to measure the square footage of a particular building, going through and adding the square feet of every room in the building for a given number of rooms - You could instead write a function to determine the square footage based on the result of a separate function used to calculate a room. This way your BuildingSquareFeet() function has just been transformed from a function for a specific building to a function that can be used on any building.

[totalwar235]

ok, this helps. thanks Duki and embooglement

[Duki]

Happy to help.