--> Jason Hendriks wrote to Cliff Rhodes <--
JH> CR> Make the stack as large as you have to--there is no serious
JH> CR> disadvantage within reasonable limits. You should have some idea
JH> CR> what you are doing that is gobbling up stack space. Are you
JH> CR> using a lot of very large arrays as automatic data objects?
JH>no, but this program does have a lot of objects of classes.. private
JH>data members aren't kept on the stack, are they?
Jason, any data object (private to classes or otherwise) that does not 
have static duration is almost always stored on the stack. Global 
variables defined outside any function boundary have static duration. 
Variables explicitly typed static have also static duration. These don't 
use the stack.
Almost all other variables have dynamic duration and are usually kept on 
the stack. 
class A {
  private:
     int array[100];
  ...
};
A a;   // object a has static duration since it is defined outside
       // a function body. The space for array[] is not on the stack.
int main(void)
{
   A b[50];  // The array b has dynamic duration since it is defined
             // inside a function body and is not typed static. The
             // space for 50 * sizeof(array[]) is reserved on the stack.
   ...
}
   
So, if you have a lot of classes with arrays, you can see where you 
could require quite a bit of stack space. Also, if you are passing to 
and returning from functions with objects of this sort, that can gobble 
stack space too since argument passing is done on the stack.
JH>It seemed the
JH>more code I added, the more stack space was needed.
That is not unusual in many cases, although you should try to understand 
why it is happening. You may have a problem passing composite types to 
functions instead of references or pointers. 
X CMPQwk 1.42 1692 X"Nothing so needs reforming as other people's habits." - 
Mark Twain
--- Maximus/2 3.01
---------------