0

I hear these words thrown around a lot but I don't understand what they mean in . Somebody told me to look it up in the standard but in the index there's no mention of "stack" or "heap", only stack unwinding which doesn't say what the stack is.

Do these concepts exist in C++?

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • What does that have to do with [tag:c++]? – user6361929 May 20 '16 at 15:57
  • 5
    @user6361929 The C++ standard doesn't talk about `stack` or `heap` at all, it only defines the lifetime of objects and leaves the details about it implementation defined so it's up to the platform to decide. (Although stack + heap is most common). – AliciaBytes May 20 '16 at 15:59
  • 1
    stack and heap are not c++ concepts, they are implementation details . The link talks about the real world as opposed to c++ abstractions – pm100 May 20 '16 at 15:59
  • Please re-read my question and tell me where I'm asking what the "stack" and "heap" are. There's wikipedia for that. – user6361929 May 20 '16 at 16:02
  • 1
    @user6361929 These terms are actually _meaningless_ regarding the c++ standard. They aren't even mentioned. – πάντα ῥεῖ May 20 '16 at 16:03
  • @SergeyA That probably doesn't match the kind of _heap_ asked for in the OP. – πάντα ῥεῖ May 20 '16 at 16:05
  • @RaphaelMiedl, and you are wrong too. – SergeyA May 20 '16 at 16:06
  • @πάνταῥεῖ, possibly. But your statement is still not technically correct! – SergeyA May 20 '16 at 16:06
  • 3
    @SergeyA I don't think now is a good time to nitpick about `std::make_heap` you know that's not what's being discussed – kmdreko May 20 '16 at 16:07
  • @vu1p3n0x, answers and comments should be correct. When someone is saying 'heap is not mentioned in C++ standard' this statement is simply not correct. The correct statement would be 'Meaning of heap in C++ standard is very different from what you probably mean in your question...'. – SergeyA May 20 '16 at 16:09
  • 1
    @SergeyA the meaning concept he talks about doesn't exist, is it really better if we were to talk about something completely different with the data structures? I kindly disagree with your opinion. – AliciaBytes May 20 '16 at 16:11
  • 3
    @SergeyA yes, you are correct but that doesn't help address OPs problem – kmdreko May 20 '16 at 16:11
  • 1
    @vu1p3n0x, I am not sure what kind of **problem** OP has in the first place! – SergeyA May 20 '16 at 16:19
  • 2
    @SergeyA he talks about the `free store` above, so it's safe to assume he didn't talk about the data structures in my opinion, the way most people seem to have interpreted the question. – AliciaBytes May 20 '16 at 16:20
  • See: http://www.learncpp.com/cpp-tutorial/79-the-stack-and-the-heap/ – Andrew Truckle May 20 '16 at 16:30
  • 2
    @AndrewTruckle: No. Fascinating example of precisely what is being talked about. That article discusses some particular implementation and doesn't even bother to declare which! This question is about the language. – Lightness Races in Orbit May 20 '16 at 17:05
  • @LightnessRacesinOrbit OK! Thanks for letting me know! – Andrew Truckle May 20 '16 at 17:21

3 Answers3

5

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.

πάντα ῥεῖ
  • 1
  • 13
  • 116
  • 190
  • 2
    And there are even some implementations that implement these concepts without a stack/heap, see: [Are there stackless or heapless implementation of C++?](http://stackoverflow.com/q/10900885/1942027) (might depend somewhat on the definition of stack/heap though). – AliciaBytes May 20 '16 at 16:25
  • @RaphaelMiedl Very good point, substantiating my answer. _"might depend somewhat on the definition of stack/heap though"_ Well, at least the c++ standard doesn't provide one. – πάντα ῥεῖ May 20 '16 at 16:33
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.

Community
  • 1
  • 1
Lightness Races in Orbit
  • 378,754
  • 76
  • 643
  • 1,055
0

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

SergeyA
  • 61,605
  • 5
  • 78
  • 137
  • 2
    I really don't think this is the answer the OP is looking for. AFAICT the OP is asking for the terms as relate to the memory space that objects exist in. – NathanOliver May 20 '16 at 16:27
  • 1
    I am answering the question as asked. If it is not what OP is asking, they are free to rephrase. – SergeyA May 20 '16 at 16:30
  • 1
    @SergeyA _"I am answering the question as asked."_ That's probably a silly behavior, as many questions asked here can be nitpicked to miss a certain grade of detail. Answering that way just leaves anyone seeing that answer in future research with confusion. – πάντα ῥεῖ May 20 '16 at 16:56