Are global variables in C++ stored on the stack, heap or neither of them?

Question

Initially I was pretty sure that the correct answer had to be "None of them", since global variables are stored in the data memory, but then I've found this book from Robert Lafore, called "Object Oriented Programming in C++" and it clearly states that, according to the C++ standard, global variables are stored on the heap. Now I'm pretty confused and can't really figure out what's the correct answer to the question that has been asked.

Why would global variables be stored on the heap? What am I missing?

EDIT: Link to the book - book page 205 / Google Drive page 231

Aleutian

" and it clearly states that, according to the C++ standard, global variables are stored on the heap" - I really doubt it clearly says that. Post the relevant text. – Henequen

@NeilButterworth I've edited the question and added the link to the book, if you want to look up there. Anyways, it says "If you’re familiar with operating system architecture, you might be interested to know that local variables and function arguments are stored on the stack, while global and static variables are stored on the heap." – Aleutian

The book is wrong. They are not stored on the heap. They are stored on the data segment or .bss segment. – Bunt

Well, that certainly isn't true. C++ doesn't say explicitly where they are stored, but no implementation I'm aware of stores them on the heap. – Henequen

Ok guys, thanks for your help. That really confused me. – Aleutian

Answer 1

Here is what the book says on page 205:

If you’re familiar with operating system architecture, you might be interested to know that local variables and function arguments are stored on the stack, while global and static variables are stored on the heap.

This is definitely an error in the book. First, one should discuss storage in terms of storage duration, the way C++ standard does: "stack" refers to automatic storage duration, while "heap" refers to dynamic storage duration. Both "stack" and "heap" are allocation strategies, commonly used to implement objects with their respective storage durations.

Global variables have static storage duration. They are stored in an area that is separate from both "heap" and "stack". Global constant objects are usually stored in "code" segment, while non-constant global objects are stored in the "data" segment.

Veta

"Stack" and "heap" are definitely related to storage duration, but that's not what they are. Stack is an allocation strategy suitable for objects with automatic storage duration, and heap is an allocation suitable for objects with dynamic storage duration. (Of course, neither is really suitable for objects with static storage duration.) – Muns

I know this is valid for the elf format, but is this valid for others as well? – Hawkshaw

@Hawkshaw You mean the "data" and the "code" segments? Most formats have segments that serve similar purpose, although names are often different (e.g. "code" segment is often called "text" segment). – Veta

Many C toolchains have two segments for global variables: One (traditionally called "data" in Unix land) is for global variables with compile-time-constant initializers, and the other (traditionally called "BSS") for globals that get initialized at run-time. The executable file contains the actual initial values for the variables in the "data" segment, but for the BSS it only has to say how big to make it. – Sixtyfourmo

Thanks for answering the question in terms of storage duration. My follow-up question is whether global non-constant objects count towards the stack size limit of a process. Since they are stored in the data segment, it sounds like they are part of the stack. The typical stack size is on the order of 2MB. But I was able to define and write into a global array with 48MB size ("static uint8_t buffer[48 << 20]"), which definitely exceeds the 2MB limit, without encountering stack overflow error. – Theatheaceous

@DarsenLu Even non-constant global and static objects (which are the same as globals, but with reduced name visibility) are stored outside the stack. That is why your globals did not overflow stack. – Veta

Are those "data" and code" segments part of static storage duration? – Savona

Answer 2

The relevant quote from the book is on page 205:

If you’re familiar with operating system architecture, you might be interested to know that local variables and function arguments are stored on the stack, while global and static variables are stored on the heap.

This is simply wrong because global variables are typically stored in a static memory section such as .data, or .bss, and these sections are allocated during program startup, not dynamically through e.g. std::malloc.

Furthermore, the C++ standard doesn't say anything about the stack or the heap; the C++ standard only concerns itself with storage duration, i.e. when storage is obtained and released for an object. Allocation strategy is the way that the implementation allocates storage when it is needed. Here is how the two concepts correspond:

Storage Duration	Usual Allocation Strategy	Common Optimizations
static storage duration e.g. global int, local static int, etc.	static memory section, e.g. .data, .rodata, .bss	no memory, only register for global constants, especially constexpr
thread storage duration , anythingthread_local	TLS (thread-local storage)
automatic storage duration, i.e. local int, function parameters, etc.	stack memory	very often optimized to use only registers, especially for small types like int and float
dynamic storage duration, i.e. storage was obtained via std::malloc, new, etc.	heap memory	heap elision if possible, i.e. use registers instead (powerful compiler needed, optimization can often not be applied)

Of course, one common optimization I haven't yet mentioned is that if the compiler can tell that any object is unused, it can also completely remove it. In that case, a global variable is not stored anywhere, it just disappears.

Downe