[lug] Huge stack size--any reason to avoid?

[Tom Tromey]

>>>>> "Vince" == Vince Dean <vdean at ucar.edu> writes:

Vince> I'm working with some C++ code which puts very large 
Vince> data structures on the stack

Vince> The developers point out that variables on the stack are
Vince> managed automatically, minimizing the risk of
Vince> memory management errors.

FWIW I don't really buy this argument for a C++ program.

Part of the design of any C++ program is deciding on your memory
management approach.  And, C++ has some features which make it fairly
simple to automatically manage allocations -- the whole RAII idiom
thing.  (Also I'm sure Boost and other libraries provide extensive
support as well...)

Also there's valgrind, which in conjunction with your test suite ought
to offer a reasonable assurance that you're doing things correctly.

Vince> Are there any practical arguments against putting
Vince> big data structures on the stack?

As I recall on some platforms, a large stack allocation requires the
compiler to emit explicit stack probes.  My recollection is that this
is a workaround for a safety check somewhere.  I suppose it could
negatively affect performance... but you'd really have to measure
that.  (I could be remembering the details of something other than
Linux... hard to say :-)

Also I'd imagine this interacts poorly with threads.  But, maybe you
aren't using threads.

Overall my feeling is that this is somewhat ugly.  It is probably not
a big problem for execution.  It may eventually be a problem with
maintenance, but that is hard to predict.

Tom