Is there memory area called 'stack' in C++ to store automatic variables

Is there a specific area in memory called stack in C++ where automatic vari开发者_JS百科ables are getting stored.

No. The standard only mentions:

— static storage duration

— automatic storage duration

— dynamic storage duration

There is no such thing as 'stack memory' in C++. Yet it's common to say that the automatic storage duration variables are 'allocated on the stack' since it's the way it's implemented from computer science point of view. 'The heap' is another term that usually refers to dynamic storage duration but is not mentioned in the standard.

• Most processors have a memory area called the stack.
• C++ compilers typically use the processor stack for automatic variables but are not required to do so. One very common case is when a variable is kept in a processor register and never stored to memory.

This question seems to have generated a debate about whether the correct answer is what is defined by the standard, or what is actually done in most if not all implementations. Rather than continuing to snipe with comments, let me give a long answer.

A simple analogy: Suppose that you were trying to teach someone beginning geography. At one point the student asks, "Is France in Europe?" What would you consider the correct answer to such a question?

(a) No. The French Constitution does not specify the borders of the country. Therefore, it is impossible to say where France is.

(b) No. It is possible that someday in the future the Earth will be destroyed and French refugees will settle on another planet and reconstitute their nation there. Or there may be alternative universes in which France is located in a different place. Therefore, we cannot say where France is.

(c) Yes. France is in Europe.

(d) Basically yes. The central government and the bulk of the population of France is in Europe, though they do control territories elsewhere, like French Guiana in South America and Reunion Island in the Indian Ocean.

I would give answer (c) if the question was being asked in a general way or by a beginning student, or (d) if the context indicated that a more precise answer was called for. Apparently some of the posters here insist that the correct answer is (a) or (b). They say that it is literally WRONG to look at the world as it actually is, and that the only correct answer to a question is to look for some document that describes the world as some authority declares it ought to be.

If you think this analogy is strained and you want a more purely IT discussion, let me offer a closer analogy. Suppose you are teaching a class on web design and a student asks, "How can I express complex mathematical formulas in a web page?"

Would you say that the correct answer is, "Use the <MATH> tag, and it's associated tags like ABOVE and BELOW and ROOT and ARRAY, as defined in the HTML 3.2 standard."

Such an answer would be absolutely true in the sense that the HTML 3.2 standard does include such tags. Unfortunately, no major browser implements these tags. The fact that it is in a standard is not of much practical use.

I could say the same about many features of IT products. "How do I limit the number of rows of output from a SQL query?" The real answer depends on which database engine you are using. Off the top of my head I don't know what the SQL standard says, if it provides any means at all, and I don't care, because it doesn't matter. In real life I do not run the ANSI SQL standard on my database server, I run Postgres or Oracle or MySQL or some other actual product.

I'm not saying that standards don't matter in general. OF COURSE we should have good standards, and products should comply with them to the maximum extent possible. But in the real world, what ultimately matters is implementation.

To insist that it doesn't matter how the computer ACTUALLY works in real life, but that we can ONLY consider how someone said he thought it should work, is not useful to someone trying to write programs that run on real computers.

(Yes, there is a practical case to be made for writing programs that will work with any standards-compliant compiler, if you're interested in cross-platform compatibility and upwards compatibility. We could certainly debate the wisdom of using tricks that depend on a specific implementation: when is performance or coding convenience outweighed by the fragility of a non-standard implementation?)

Frankly, I think this sort of answer is a pedantry that just confuses the beginning student. When the beginning student asks what continent France is on, he doesn't want or need a long string of hypotheticals, theoreticals, and special cases. He needs a simple and direct answer. Same thing with when he asks, "Are my function variables stored on a stack?" or "Is my program loaded into RAM at run time?"

Vague question, but yes. A program's stack in C++ typically starts high in the virtual address space of the program and moves 'down' towards the virtual address space of the program heap.

EDIT:

Because I have started a controversy in saying yes to this, I will append to the answer. The C++ standard does not call specifically for a stack to be used to implement local storage. It is, however, a common implementation practice to do so as described above.

Please refer to this answer, where I explain this in detail.

In summary, quoted from it:

The terms "heap" and "stack" are outdated, relating to back when the most popular runtime libraries used these data structures to store objects which were dynamically- and automatically-allocated, respectively (statically-allocated objects fit into neither category, incidentally).

These days that is not always true, and it's certainly not mandated by the C++ standard, which does not care where things are stored. It only cares about how they are created and destroyed, and about how long they live.

Hope that clears things up for you.