On Aug 16, 7:20 pm, Malcolm McLean <malcolm.mcle...@btinternet.com> wrote: > On Aug 16, 10:20 am, Standish P <stnd...@gmail.com> wrote:> [Q] How far can > stack [LIFO] solve do automatic garbage collection and > > prevent memory leak ? > > Most programs can be written so that most of their memory allocations > are matched by destructors at the same level. > > However the allocations that can't be written this way typically tend > to be the small frequently-called ones used for nodes in dynamic graph > objects, or small resizeable buffers to hold strings and the like. > This is where you get the performance hit with repeated calls to > malloc() and free(). > > So generally it's not worthwhile writing a stack allocator for a > normal program. That's not to say there aren't a few individual cases > where it can help performance. (See the chapter "Memory games" in my > book Basic Agorithms for details about memory allocation strategies).
Even if it's a troll, it was droll. In a language that of necessity has a runtime stack or something that works like a stack (eg., a stack) one finds that the need for explicit stacks is lessened. For example, in my compiler for [start shameless plug] "Build Your Own .Net Language and Compiler [end shameless plug] I did not need to use an explicit stack to do recursive descent. Instead, I simply called finer grained procedures, passing the compiler state as a parameter, allowing the runtime stack to manage the return. To build an explicit stack in this program would have been folly, for it would have been necessary to either preallocate the stack and thus legislate the maximum complexity of source code, or use a lot of memory management in the pre-existing runtime heap. You didn't tell us you published a book. Can you identify the publisher? -- http://mail.python.org/mailman/listinfo/python-list