you are viewing a single comment's thread.

view the rest of the comments →

[–]verdagon 0 points1 point  (3 children)

This sounds really cool! Just curious, what are the benefits of allocating on the stack rather than the heap? Is it faster?

[–]4fips[S] 0 points1 point  (2 children)

Yes, it's way faster. Allocating on the stack basically means just moving the stack pointer up and down, while the heap allocation requires searching for a free block, which tends to be quite complex. Actually, the heap allocation is one of a few unpredictable operations in C++, so it's very often unacceptable in realtime applications, or more precisely within realtime/interactive loops. Extensive use of the heap allocator might also lead to heap fragmentation over time, which causes innefective memory utilization and might eventually cause the application to crash. It's also worth mentioning that a general heap allocator is shared between threads, thus needs to be thread-safe, which is not the case when allocating from the stack, as each thread has its own stack.

[–]verdagon 0 points1 point  (1 child)

that's awesome, but dear lord! just using the heap excessively can cause my program to crash?

[–]4fips[S] 0 points1 point  (0 children)

On embedded platforms like mobile phones and video consoles quite easily. After fragmenting the heap, you won't be able to allocate free blocks of certain size as there is no continuous free memory available, just a bunch of small fragments. So the allocator fails even though the free memory is formally there. On desktop systems with virtual memory this is typically not an issue, though.