I'm looking for a way to wrap stack allocations in abstract data types. For example, I'd like to have a vector which can work strictly via allocations on the stack. My biggest hurdle of course is that alloca
works only within the current stack frame -- thus I don't see an easy way to wrap this into a function.
So far the only way I see to do this is by using macro-like functions which are guaranteed to be compiled into a given stack frame. I don't like this approach since it isn't as type friendly as one would hope, and requires more verbose naming than desired.
Is there anyway I can get a function to allocate on its caller stack? I understand this would normally destroy the immediately calling stack, thus likely the function would also have to be forced inline somehow. I'm not clear on what options I have, so I'm looking for some ideas, or pointers towards possible options.
Notes:
The ultimate goal is something like a std::vector
which works strictly on the immediate functions stack. Obviously it would only be passed as a const
object to callees, and its life ends with the function.
C approach is fine so long as it is better than my macro based approach. Though some support macros are also acceptable.
I understand this is a fairly specific optimization, and optimally I'd like to be able to (with a flag) turn it on/off (using just an normal std::vector for debugging). It would give a minor speed boost to significant parts of our code, but probably not enough to justify making it unreadable via too many odd constructs.
Answer: Is most likely that it isn't possible and that only the macro approach would work.
The stack is really not a good fit for the kind of allocations that a container class uses. For example, when a vector needs to expand its
capacity
, it most likely allocates a new region of storage, copies the existing items over (hence the C++ requirements on copy and default constructors for objects used in containers), and releases the original storage. Needless to say, this plays havoc with stack-based storage, which cannot be released until the function exits. (The only wayvector
could expandcapacity
in-place without copying is using therealloc
function, which has no C++ equivalent, and most importantly to you, noalloca
equivalent.)Further,
alloca
only really works with POD-types in C++, which containers most definitely are not.EDIT: The answer to this question partly solves the problem: It allocates the initial storage for the
vector
from the stack, but if further capacity is needed, then it allocates from the heap.You can always implement your own custom allocator that will be as efficient as thread stack. From my experience alloca can be very dangerous, and if hidden in some C++ class hierarchies (ie. in for loop) can easily blow your stack.
Well, if you only need to allocate once (that is, if you have a maximum capacity that will always be sufficient), you can call
alloca
inside a default argument:The main benefit of using stack allocation is probably the by-pass of the standard library malloc/new allocator. In this light, using the stack is not the only option.
One alternative to stack allocation is using a custom memory allocator based on
mmap()
system call. The memory allocated bymmap()
can be used as storage for the custom allocator instead of the stack. To avoid callingmmap()
often the memory region allocated bymmap()
should be cached, in a global thread-specific variable, for example.You can't.
When a function returns, its stack is unwound, and the stack pointer goes back where it was before. It has to, if you don't want a real mess. All alloca does is move the stack pointer, so a function return undoes this allocation.
Macros would work, because they just add code to the same function. But it would be ugly, with no real hope of improvement.
Here's an example macro for allocating an on-stack array, which takes advantage of C++ type-safety and compile-time checking as much as possible via a helper inline function: