[lmm]

> On the heap, allocation might be cheap or it might be expensive, deallocation might be cheap or it might be expensive,

In other words it might behave just like "the stack"; the differences between different kinds of "heaps" are as large or larger than the difference between "the stack" and "the heap".

> fragmentation is a risk, the resource is 'unlimited', and the lifetime is unscoped.

None of these is true in all implementations and circumstances.

Understanding the details of memory management performance is important for particular kinds of programming. But learning C's version of "the stack" and "the heap" will not help you with that.

[arcticbull]

I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept. The heap, however, is left as an exercise to the reader.

[lmm]

> I'd argue that given special purpose registers exist on most platforms to support a stack, and instructions dedicated to manipulating them (x86 %sp, push, pop) that the stack is in fact a hardware concept.

True enough; however sometimes access to "the heap" (in C terms) will use those instructions, and sometimes access to "the stack" will not. Learning one or two assembly languages is well worth doing, since they offer a coherent abstraction that is genuinely relevant to the implementation of higher-level languages. Not so C.