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
kishjAsked:
Who is Participating?
 
nietodConnect With a Mentor Commented:
>> 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.
No the standard definitely does not make any statement to prevent this.  The standard does insure that the array will not ever be initialized (if the items in it have non-trivial constructors) unless the scope it is in is entered, but the spare for the array may be allocated at any time.

so a compiler may allocate space for ALL of a function's locals when the function starts, even if some of those locals won't ve constructed.  In fact, virtually ever compiler in the world will do this, because they will use a stack frame to access the locals and you can only have one strack frame at a time (on most CPUs at least) so you need  to provide the space for all the locals at one time.

Let me know if you have any questions.
0
 
nietodCommented:
>> The work around was to put the code
>> 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.
0
 
KangaRooCommented:
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.
0
 
nietodCommented:
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.
0
 
kishjAuthor Commented:
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
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.