I don't know more about memory than Heap and Stack, the Chapter 4 explains that fixed size data is in the Stack, and then suddenly says:
In the case of a string literal, we know the contents at compile time, so the text is hard-coded directly into the final executable.
Is this valid for all non-mutable Stack data ? Is the final executable itself on the Stack ?
What would be a good way to harmonise this memory (assuming it's different), with the prior knowledge of Stack and Heap? Is this string literal then not in the Stack, or maybe I misunderstood ?
Relevant (not too hard) links are welcome if this is too long to be explained here.
The first thing you need to load and run your program is some memory in which to actually load all those executable instructions. Let's call that memory area "text". Because that is what it is called in the executable file format.
Of course as well as actual program instructions this is a good place to keep values of the constants in your program. Things like "Hello world!" as a sequence of chars or the value PI as a floating point format number. In this way such "literal" values in your source are actually found in the same memory area as your executable code.
When your code starts to run it will also reserve an area for static/global data.
Then it will set up a stack area and a heap area.
NB: A lot of simplification going on here.... but the point is there is more than just stack and heap in the story.
Chapter 4 is one of the worst, needlessly hard, chapters of The Book.
The problem is that it explains things that are not hard and explains them using other things that are really complicated and convoluted… but that are, supposedly, known to the readers because of years of experience.
No. Variables that belong to a particular function go on stack. And thus stack turns into Pez dispensers: data that belongs to functions that started eraly are pushed deeper into the dispenser, while functions that are “new“ are closer to the “dispenser head”.
Literals, constants, don't belong to the stack: they exist “forever”[1]. The difference is important because for stack variables, even variables very far from the “dispenser head” would still be extracted, sooner or later… but literals are there and would always be there [2].
And heap is for variables that don't belong to these two neatly-organized categories.
Book uses all that, pretty advanced, info to explain how simple things work for a historical reason: all developers with decades of experience know about stack, heap and binary executable mappings… that's why this chapter was based on stack and heap with casual mention about something being “hard-coded directly into the final executable”.
or is that also too difficult? The fact that an compiled executable is loaded in memory when you run an application is indeed a fact that is important and should be mentioned in an introduction. I think I will add that as a short note early in my book.
Have you returned again to the original book, or are you reading still the variant from Brown University? My feeling is, that one needs a lot energy and time to manage the Brown book, especially for chapter 4. Parts of the book are really nice, but these in-depth explanations early in the book makes the progress quite slow.
I have not found the book hard in the sense that heap, stack, pointers etc. are all new to me, but were clearly explained.
For my style, exercises and their permissions' diagrams are excellent.
I am only re-reading base-book Ch 4 because the first section is quite different. But in both books I've read up to Chapter 9. (almost all other chapters are nearly the same, so it's fast to do.)
I will take a look at your book once I past Chapter 12 were one applies the knowledge.
Oh that is great. As you just asked a question related to chapter 4, I got the impression that you are still stuck there. You must be really smart understanding all that stuff -- I think I would have not be able to manage that when I started computer programming some decades ago with the C64
