kishj
asked on
Borland C++ compiler, Stack issues/question
This is related to Borland 5.02 C++ compiler for an OWL program.
Someone I work with noticed this occurring for large variable:
owlclass::routine1()
{
if (x)
{
call routine2()
}
else
{
averylargevariable1[1000]
}
}
owlclass::routine2()
{
averylargevariable2[1000]
}
When x was true and they stepped into routine2() the stack blew up, BUT (Here is the weird part)
if the size of averylargevariable1[1000] was changed to [2], the program worked fine.
It appears that the space for averylargevariable1[1000] was being allocated even though the curley braces were not currently being entered which, I believe is a C++ standards no - no for the compiler.
Maybe something weird is happening with the optimizer or something?
Can anyone make any pertinent comments here, or suggestions? It just seems like some weird compiler behavior . The work around was to put the code and allocation in the curley brackets around averylargevariable1[1000] in its own set of curley braces.
Thanks
Jeff
Someone I work with noticed this occurring for large variable:
owlclass::routine1()
{
if (x)
{
call routine2()
}
else
{
averylargevariable1[1000]
}
}
owlclass::routine2()
{
averylargevariable2[1000]
}
When x was true and they stepped into routine2() the stack blew up, BUT (Here is the weird part)
if the size of averylargevariable1[1000] was changed to [2], the program worked fine.
It appears that the space for averylargevariable1[1000] was being allocated even though the curley braces were not currently being entered which, I believe is a C++ standards no - no for the compiler.
Maybe something weird is happening with the optimizer or something?
Can anyone make any pertinent comments here, or suggestions? It just seems like some weird compiler behavior . The work around was to put the code and allocation in the curley brackets around averylargevariable1[1000] in its own set of curley braces.
Thanks
Jeff
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
This might be due to the fact that in C calling convention the caller has to set up and pop the stack (for var args functionality) for the called function.
Sort of, its more due to the way the stack frame is created. The stack frame is the portion of the stack used to store the locals. This portion is not necessarily the top of the stack (it is the top when the function starts, but not necessarily the top later.) so it can't be exapanded at will as new variables come into the scope.
ASKER
I'll have to check the standard, but Thanks! This is good information.
I am fighting the battle of when we want to take the hit.
Jeff
I am fighting the battle of when we want to take the hit.
Jeff
>> and allocation in the curley brackets around
>> averylargevariable1[1000] in its own set of
>> curley braces.
But that work-around didn't work, right? Its a "not work-around" right?
One solution is to expand your program's stack space. There is likely to be a linker option for this
Another solution is to use dynamically allocated memory (new). This memory will come from the heap, not the stack, so you won't get a stack overflow. (You could run out of heap space, but that is less likely, the heap is usually much larger than the stack.)
Another option is to use an array class, like vector<>. This is sort of a combination of the two approaches, the vector is local and gives you the conveneince of a local variable, but the array storage space comes from the heap and has a better chance of being allocated.