Quote:
|
Usually stack memory is severely limited, whereas heap memory is far larger.
|
Simply because this statement is not unequivocally true. Back in the days when the stack was severely limited, the heap was generally severely limited (or nonexistent), too. Given a system with a certain amount of memory, one can generally alter the amounts of memory dedicated to each of these from certain default values.
Now, in the world of multiple processes, each user (let's say they're all C/C++ programs) gets so much memory for global/static data, so much for code, and so much for stack (presuming the really common implementation that actually uses stack, and frequently the processor's call stack). The heap is an area common to all and belonging to none until memory is borrowed, by one of the processes, using malloc or new or kin. You are expected to return this borrowed memory. Generally speaking, returning the memory with delete or free doesn't actually put the memory back on the common heap. It's free for use by the process that originally borrowed it. It is returned to the heap when the program exits or when the program overtly returns it to the heap.
Once again, you must distinguish between how an implementation chooses to work with the language, and what the language expresses as requirements. It would be stupid for the language to try to specify what kind of keyboard or drive or display you have. It would be stupid for your keyboard or display to specify what language you must use. You must have intermediaries that marry the two. That's called platform dependency.
Many, many machines still use a processor-controlled stack, often the call stack, to manage local variables, argument passing, and so forth. It's just a fairly simple way to accomplish the task. These machines mostly DO have registers in addition. I don't know of a commercially viable one that doesn't, in fact. I have only used one uP that didn't implement a call stack. That was an old one, and a piece of crap. Many of the earlier non-micro processors did not implement such a beast. Call tracing and parameter passing were the job of the programmer.
I have at least one post on the forum that describes call-stack operation. It is generalized but fairly detailed, as usage varies somewhat from processor to processor and language implementation to language implementation. See
here.
Incidentally, if you look into your compiler documentation, you can PROBABLY find a way to increase your stack space and heap space.
Today's typical desktop machine (large numbers, but definitely in the minority when it comes to all computers) often have grossly huge amounts of memory. The term 'severely limited', in reference to such machines, should not be used by a knowledgeable, modern author. Of course, I also take the position that "Learn ________ in 24 hours (or days, or weeks)" is a flagrantly stupid and misleading statement. It's the ploy of a used-car salesman or a politician or some other brand of thief, cheat, liar, or crook.