2

I encountered this statement(source):

means putting the function calls and scopes in a stack

But how/why would you store scopes?

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • It's not so much that you "store scopes in a stack" as that the fact things are stored on the stack, gives them a scope. If that doesn't make sense immediately, please read up on the difference between heap and stack allocations. –  Nov 08 '17 at 10:56
  • scope is just a term that means recent stuff (function calls, variables, parameters) is pushed into the stack, which is part of the RAM. – samthegolden Nov 08 '17 at 10:59
  • It’s not that **you** store scopes in a stack; the **compiler** does that, to keep track of what’s where. When the code starts a block the compiler creates a new record for variable names and pushes it on a stack; when variables are defined their names go into the most recent record. When the code leaves a block it pops the last record off the stack and discards it. That removes all the names that were defined in that block. – Pete Becker Nov 08 '17 at 13:14

2 Answers2

1

That statement could be better phrased. You need to make some observations first.

  1. A scope is a semantics construct. It defines where you can use a name (for a variable, type, function, etc.). And what that name will refer to.

  2. There are different types of scopes. Quite a few are only a compile time thing. For instance, namespaces and classes define a scope too.

  3. Functions also define scope, but functions "run". As such, their context must have some sort of run-time representation.

  4. Recursion entails calling the same function, but the functions context must be different for each re-entrant call.

The last point is why "call stacks" are often used to implement function calls. Each stack record relates to the context of the function being run. The names in the functions scope will therefore be referring to items on the call stack.

StoryTeller - Unslander Monica
  • 165,132
  • 21
  • 377
  • 458
  • Thanks! But since scopes then are something that can be stored, they must be something physical in memory, right? So are scopes really stored in memory, like objects? Also, I have read a lot about scopes from different sources, such as from cppreference, but I have never encountered a statement about that scopes are stored somewhere, why is that? Is this also covered somewhere in the Standard(I have to search it through)? Thanks! –  Nov 09 '17 at 09:11
  • @sdsadasdasd - Scopes aren't stored. They are a semantic concept. A functions context is stored, and scope for a function defines what will be in that context. But the scope is *not* stored. – StoryTeller - Unslander Monica Nov 09 '17 at 09:13
  • Hmm okay, but if the functions' context is stored somewhere in memory, I still do not get how exactly each entity is associated with its scope if scopes aren't stored directly? Is it done in the symbol table or are functions' context stored somewhere in memory, where this place is dedicated to a certain scope? You have made me understand much more though, but I still have some wonders :) –  Nov 09 '17 at 09:18
  • @sdsadasdasd - That is up to the implementation, the pure language doesn't touch on that. The thing which translates the concepts as defined by the C++ language into run-time properties of the generated code, decides how. A popular implementation is to use a "stack pointer". That points to the top of the call stack. The code for the function know that a variable is at `sp + 2` or `sp+4`. It's all ABI dependent. – StoryTeller - Unslander Monica Nov 09 '17 at 09:21
  • Okay thanks. Can you find where this is in the C++ Standard, because I can't? Also, what exactly do you mean by "ABI dependent" in this context? –  Nov 09 '17 at 10:02
  • @sdsadasdasd - Where what is in the C++ standard? – StoryTeller - Unslander Monica Nov 09 '17 at 10:03
  • Storing of scopes. –  Nov 09 '17 at 10:04
  • @sdsadasdasd - It isn't there. That was my point when I said scopes are a semantic concept. – StoryTeller - Unslander Monica Nov 09 '17 at 10:05
  • Ahhh okay - got it. –  Nov 09 '17 at 10:08
0

The answer isn't C++ specific. C++ uses a model of compilation prior to running (at least conceptually, implementations may differ). In the C++ model, scopes are resolved at compile time. The compiler may very well use some sort of stack data structure for this.

At runtime, there's a function call stack, and this often holds both function return addresses and the local variables of each active function, but in C++ this runtime stack doesn't need to hold scopes.

MSalters
  • 173,980
  • 10
  • 155
  • 350
  • And could this data structure be the symbol table? –  Nov 09 '17 at 09:42
  • @sdsadasdasd: That's a good starting assumption. If you'd want to _write_ a real compiler, other things come into play - real symbol tables are not a single data structure. – MSalters Nov 09 '17 at 09:50
  • But there is still something that I do not get: How memory-wise are entities connected to a certain scope? Was it by differentiating between stacks or if so, how is this stack associated with a certain class, function or whatever? –  Nov 09 '17 at 10:15
  • @sdsadasdasd: That doesn't really make sense (and suggests to me you are still not making the hard distinction between compiler and runtime environment). To just take the second word, _which_ memory are you tyring to refer to? – MSalters Nov 09 '17 at 10:22
  • Hmmm... The memory that is being used to store objects etc. (not sure if that has a specific name). Let's say that an object has the address 0x00020, is this address a certain address within a certain place in the memory that is connected to a certain scope? Like maybe the addresses 0x00010-0x00050 are dedicated to a certain scope, is that how it works? Or was it just the stack of a certain function that is connected with a certain scope? Maybe this is a slightly bad wording.. :/ –  Nov 09 '17 at 11:55
  • @sdsadasdasd: Well, it just confirms what I suspected, that you are mixing up the compiler and the run-time environment. Scope is a property of names (compile-time). Objects exist at runtime. – MSalters Nov 09 '17 at 12:21
  • Ahh okay, so the physical memory addresses and scopes cannot be connected like that... Anyway, do scopes affect where objects are stored in memory? –  Nov 10 '17 at 10:27
  • Or am I asking too stupid questions? That has happened before... :/ –  Nov 10 '17 at 13:03
  • Or could you just link me some place that has all the answers to my questions? If you won't use more time on this. :))))))))) –  Nov 10 '17 at 13:31