On 8 October 2011 10:48, Shiv Shankar Dayal wrote: >> It sounds like all you're proposing is using the stack for dynamic >> allocation instead of the heap, then adding a compacting garbage >> collector. It's easier to just use the heap and make sure you don't >> leak memory. It's not that hard. >> > > Yes. This is true that I want to use stack for dynamic memory allocation > but I do not want a garbage collector. Garbage collection should happen > though RAII.
If you're using RAII consistently and correctly then the problems associated with heap memory go away, so you don't need to avoid the heap. If you're not using RAII correctly, your proposal won't work anyway and you'll leak memory. So what's the point? Why is it better to do dynamic allocation on the stack? (Answer: it's not.) You say "A record of all allocated objects by this function has to be kept. Also, there will be gaps or fragmentation in Stack because of this for which we will have to move allocated area down almost in all cases and sometimes up." You haven't got rid of heap, you've got rid of the stack, making using the stack as complicated as using the heap. How do you propose to move the area? You have to adjust all pointers referring to it, which is not possible in the general case (even if you scan the process' entire memory to look for pointer-like patterns, they could be obfuscated or stored in a file, or outside the process in other ways.) If the stack needs to grow to call a function, but the space it wants to grow into contains dynamically-allocated objects, what happens? Does the stack skip over that block, remembering where to skip back over it when unwinding? Your stack is no longer contiguous and must keep track of far more information. A stack pointer won't work anymore. There are good reasons why dynamic memory, which has unpredictable lifetime, is kept in a separate region from stack memory, which doesn't. I agree the proposal is hopeless.
