stack-based allocation

This is a discussion on stack-based allocation within the C++ Programming forums, part of the General Programming Boards category; Hi,
I'm making an allocator with different allocation strategies. One of these strategies is a stack allocation.
I want to ...

Any way to do this without templating (allocator relies on an abstract strategy that can be stack, heap, etc)?

I am not sure what you mean here: making it into a class template should not pose a problem to your allocation strategy. I have not tried this myself, but you could define a class template with the exact same interface as std::allocator, and even implement the class template by keeping a std::allocator member and forwarding all function calls except allocate, deallocate and max_size to that std::allocator member (since the allocate member function effectively is where you implement your allocation strategy, and this must be matched in deallocation).

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Forwarding all calls except allocate/deallocate/max_size could be a great idea, thanks.

Still, anyone knows how to return the address at the top of the stack? That is, base myMemory pointer plus a given index? Compiler wants to know the size of the data when I would only want to offset it manually.

Still, anyone knows how to return the address at the top of the stack? That is, base myMemory pointer plus a given index? Compiler wants to know the size of the data when I would only want to offset it manually.

One way that you could try is to make myMemory a char* instead of a void*.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

Keep in mind that, due to alignment requirements of a particular object, you can only safely use the returned memory for objects of type T where sizeof(T) == sizeof(char).

Mind elaborating? I note that the allocate() function in eXodus31337's example differs from the allocate() function in an allocator using the interface of std::allocator since eXodus31337's version presumably allocates size number of bytes, not size * sizeof(T) number of bytes (since there is no template parameter T to begin with).

EDIT:
I went back to read an article I bookmarked on allocators, and the relevant portion is:

The standard does not guarantee that 'mem_' will have a correct alignment for something else than 'char'. And this is deadly. There are rumors that the next revision of the standard will address this problem, but until then...

To avoid the second issue, we could dynamically allocate 'mem_' (the standard guarantees correct alignment for dynamically allocated memory).

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

If we assume that myMemory is aligned to a nice 8-byte boundary when init() is finished, what is the address given to p2? It will not be aligned to a nice 8-byte boundary, I can promise. Since some processors do not "agree with" reading data at unaligned addresses, this would cause an "unaligned access" error. Sure, x86 would gladly accept this sort of thing (with a 1 clock penalty if read from L1 cache, potentially more if reading from L2 cache or external memory).

If we assume that myMemory is aligned to a nice 8-byte boundary when init() is finished, what is the address given to p2? It will not be aligned to a nice 8-byte boundary, I can promise. Since some processors do not "agree with" reading data at unaligned addresses, this would cause an "unaligned access" error.

That makes sense, assuming that the memory pool was supposed to be used by objects of different types. Unfortunately eXodus31337 is rather vague about that, and in fact I am a little confused as to whether eXodus31337 intends to follow my suggestion of copying the default allocator's interface.

I get maybe two dozen requests for help with some sort of programming or design problem every day. Most have more sense than to send me hundreds of lines of code. If they do, I ask them to find the smallest example that exhibits the problem and send me that. Mostly, they then find the error themselves. "Finding the smallest program that demonstrates the error" is a powerful debugging tool.

I guess at this point, copying -or not- the standard allocator wouldn't solve the alignment problem since it would redefine de/allocate to pick from a given block anyway.

The target is x86, but then again I'd prefer doing something portable rather than a frail implementation.

Can I assume that solving this problem would be allocating a large linear block of memory to pick from. Then picking from the top of it. Finally placing the current index at the nearest 8byte multiple?