what do heap and stack mean in C++? [duplicate]

Answer 1

The concept of heap certainly exist in C++. It is a special data structure, which is also called a priority queue. C++ standard library provides for a certain number of algorithms, which operate on random access iterators to perform basic operations on it.

Stack has two independent meanings in C++ standard. First, it is a data structure (actually, an adapter). Second, it is mentioned in stack unwiding, but is not defined independently - instead, the whole process is described as

The process of calling destructors for automatic objects constructed on the path from a try block to the point where an exception is thrown

Answer 2

I hear these words thrown around a lot ...

Yes, these are widely used coming from misconception and sticking to inappropriate terminologies, mixing hardware and OS concepts with the programming language implementation.

Do these concepts exist in C++?

As long you're referring to "heap" as dynamic storage duration, and "stack" as automatic storage duration, the c++ standard doesn't have any notion of these particular terms, but uses the other ones. So no.

Note there's no differentiation of automatic storage duration for local variables, global variables or parameters.

How's that actually done is considered an implementation detail, and in fact is dependent on the target CPU architecture and OS environment.

---

To complete the answer (that's why I said "As long you're referring to ..."):

The c++ standard library actually provides concepts for a std::stack and a heap.
But these refer to data structures, and aren't related to how memory allocation for any type instances is implemented.

Answer 3

The concepts exist, yes. The problem is that hundreds of millions of people worldwide have an abstraction leak in their brains when it comes to naming these concepts, and this has spread to the C++ world.

Sometimes, when C++ people talk about "stack" and "heap", they are discussing logical memory storage locations in hardware. It's generally a gross over-simplification in a world of registers, and optimisations, and caching. But there's a grounding in logic there.

Most of the time, though, they're simply using inaccurate synonyms for "automatic storage duration" and "dynamic storage duration", perpetuated by decades of misunderstanding and an inability or resistance to thinking in terms of abstractions.

C++ is an abstraction. It very deliberately defines an abstract machine, and the only way the standard even approaches this topic is to discuss the storage duration of objects. If you declare a local variable, it has automatic storage duration, which means it'll be destroyed when it goes out of scope. It may go into a "stack" on your executing computer, or someplace else if the computer works some other way, or it may not even escape the compilation phase! But people still will insist on saying that this variable is "on the stack" because they think doing so is somehow simpler. That's their right, I suppose, but they're still objectively wrong.

Similarly, when writing std::make_unique<T>(args...) (or new T(args...)) you are creating an object of dynamic storage duration, whose lifetime escapes the immediate scope and will only be destroyed when the std::unique_ptr dies (or when you use delete). These generally won't be optimised out, but there's no way of knowing whether the physical target platform will use a "heap" data structure to implement what C++ calls the free store. If you have a C++ implementation running on an orange, for example, then it seems unlikely.

So, in conclusion, if you use the terms "on the stack" and "on the heap", then you'll be understood by many but derided by some. The C++ standard is one of those sensible few, and doesn't use these terms at all.