For those new to message boards please try to follow a few simple rules when posting your question.
Choose the correct forum for your message. Posting a VB.NET question in the C++ forum will end in tears.
Be specific! Don't ask "can someone send me the code to create an application that does 'X'. Pinpoint exactly what it is you need help with.
Keep the subject line brief, but descriptive. eg "File Serialization problem"
Keep the question as brief as possible. If you have to include code, include the smallest snippet of code you can.
Be careful when including code that you haven't made a typo. Typing mistakes can become the focal point instead of the actual question you asked.
Do not remove or empty a message if others have replied. Keep the thread intact and available for others to search and read. If your problem was answered then edit your message and add "[Solved]" to the subject line of the original post, and cast an approval vote to the one or several answers that really helped you.
If you are posting source code with your question, place it inside <pre></pre> tags. We advise you also check the "Encode HTML tags when pasting" checkbox before pasting anything inside the PRE block, and make sure "Ignore HTML tags in this message" check box is unchecked.
Be courteous and DON'T SHOUT. Everyone here helps because they enjoy helping others, not because it's their job.
Please do not post links to your question in one forum from another, unrelated forum (such as the lounge). It will be deleted.
Do not be abusive, offensive, inappropriate or harass anyone on the boards. Doing so will get you kicked off and banned. Play nice.
If you have a school or university assignment, assume that your teacher or lecturer is also reading these forums.
No advertising or soliciting.
We reserve the right to move your posts to a more appropriate forum or to delete anything deemed inappropriate or illegal.
I suspect maybe that is a bit different especially given the OP.
C, so before C++, would limit the scope to the method. C++ would have been based on the same. So if one has 3 for loops in one method with each in a block for a if statement, the compiler might or might not have limited it to the block.
What you refer to makes that explicit. The compiler thus must reuse the stack space.
The OP though is referring both the scope which is a method and, I believe, to each iteration of the for loop.
I should have read your original post more carefully....
The following is part of what the OP posted.
"allocate memory for an int every frame."
To me the terms I underlined are significant.
Most compilers that I have ever seen, not just C/C++, use a 'stack frame' to manage the variables within a method.
The allocation, far as I can tell, is how the OP is referring to, because the post specifically uses those terms.
But it is still up to the compiler. As a matter of fact at least at one time compilers at one time made a big deal (advertising) that the method variables were managed as CPU 'register' values and were not put onto the stack frame at all. And that is definitely not in the specifications for C or C++.
I do know, because I looked at the assembly that compilers used to emit (and at times modified it) that compilers at one time did nothing more than allocate variables on the stack frame sequentially. I might even recall reading an article that a developer would need to manage variables more carefully to limit that. (I can perhaps recall the suggestion that all variables should be declared at the top of the method for that very reason.)
Now back to what you posted...
For what you posted the "scope" refers to where the variable is visible from. At the language level.
That does NOT specify how the compiler is to manage the variables.
Do you have a different specification, which would probably need to be after C99, that does state how the stack frame is to be managed? I say C99 since I was familiar with that one and I am rather certain that it says nothing at all about the stack frame.
I also looked through my books for "C++ Programming Language" and "C Programming Language" and found nothing at all about the stack frame. I did not expect to find it.
I did look through the Dragon book where I would expect this to be discussed. It doesn't use that term instead it uses the term 'activation record'. It discusses how the activation record can be managed by a stack.
But you would probably want to read: 6.2.4 Storage durations of objects
I use to read all these many years ago, I stopped reading the specs after C11
At Microsoft we had a huge internal mailing list where everyone got to watch the compiler team go back and forth over the new language features. The gatekeeper of the STL library had the initials S.T.L. I always thought that was funny.
But 6.2.4 says nothing about how a stack frame is built.
Just as with your other reference it explains what the compiler must enforce but not how it must enforce it.
Following is the only thing that relates to the language
4 An object whose identifier is declared with no linkage and without the storage-class specifier statich asautomatic storage duration.
5 For such an object that does not have a variable length array type, its lifetime extends from entry into the block with which it is associated until execution of that block ends in anyway.(Entering an enclosed block or calling a function suspends, but does not end, execution of the current block.) If the block is entered recursively, a new instance of the object is created each time. The initial value of the object is indeterminate. If an initialization is specified for the object, it is performed each time the declaration is reached in the execution of the block; otherwise, the value becomes indeterminate each time the declaration is reached.
The second paragraph is the only one even close to relevant and basically makes the same point as your other reference.
It does not specify how it is built on the stack frame.
Again a compiler writer could make a fully compliant compiler which used new slots on the stack frame for each block. Or it could reuse existing ones. Both implementations are compliant.
The referenced section allows a compiler writer to produce optimized code that reuses the slots. And they cannot be considered non-compliant if someone attempts to use a declared variable in a block outside the block (for example via a pointer.)
Consider exactly that case - using a pointer outside the block.
1. Compiler A uses new slots so the code works.
2. Compiler B reuses slots so the code doesn't work.
The user complains that Compiler B is non-compliant. The creators can tell them explicitly that they are using code that the spec does not support.
But it says nothing about Compiler A. Compiler A is NOT required to attempt to determine that a pointer belongs to a variable that goes out of scope. (Similar to having a method return a pointer to a local variable.) The compiler might choose to warn about that but is not required to do so.
If variables X and Y are defined in a block, must they both be available throughout the lifetime of that block?
If the compiler does a complete flow analysis, detecting that variable X is only used in the first half of the code, and variable Y only in the second half, with no overlapping use possible for any possible execution path, can then X and Y share the space?
For the running code, sharing would be OK. A debugger might display both X and Y as soon as the block is entered, and all the time until the block is left. If X and Y share a location, then Y would be incorrectly displayed for the first half, X for the second half. Does anything in the C++ standard forbid this? Does the language standard at all relate to tools like debuggers, or only to the executing program code itself?
Consider what difficulty the compiler has in determining what the scope of A is in the following. Keep in mind that the code can get much more complex.
int A = 3;
int *B = &A;
int **C = &B;
This is the kind of examples that tend to give great respect for those people trying to optimize C/C++ code. And also a great pity with them.
If variables X and Y are defined in a block, must they both be available throughout the lifetime of that block?
Via the spec? No.
Regarding C99 the lifetime is defined in 6.2.4 paragraph 2:
The lifetime of an object is the portion of program execution during which storage is
guaranteed to be reserved for it. An object exists, has a constant address,25) and retains
its last-stored value throughout its lifetime. 26) If an object is referred to outside of its
lifetime, the behavior is undefined. The value of a pointer becomes indeterminate when
the object it points to reaches the end of its lifetime.
Then paragraph 5 defines how that "lifetime" is applied in the block scope.
Either, the C/C++ scoping/life time rules apply to the source code only and how it 'conceptually' is executed, and does not relate to the compiled code and how it actually runs.
Or, the C/C++ standard does not, strictly speaking, allow optimization of the kinds that we are talking about here, such as allocating a variable in a register, reuse of stack locations within a single scope, or removing variables entirely.
I don't know which is correct. To me, it is the running code that matters, even if the correct interpretation of the standard is that it doesn't care about the generated code.
The question is how the C/C++ standard defines its own scope. How far does the authority of the standard reach. How does it define which parts of the system must be compliant to the standard for the system to call itself standard compliant. Does it stop at the parser, or could an optimizer have any effect on whether the system is compliant.
This is more a "meta-question", not something you will find in the syntax description pages. If you find it at all in the standard text about the authority and scope of the standard itself, and which parts of a system must comply to the standard, it is probably in some introductory or concluding chapters. I do not expect it to be in the standard itself, and if it is there, I expect the wording to be so formalistic that you have to have some experience from working in the standards committee to get it right.
I did pick up a copy of a late-in-the-process draft documents, but the final document is too high priced that I am willing to pay that much for the spec of a language I use very rarely nowadays. I tried to read the drafts, but they were too huge for me to read every word - and in particular: to understand every word of it
It reminds me of this old blog post: This processor has no stack
Slight sidetrack: Fortran did not allow recursion until the Fortran 90 version; the memory usage was fixed. One of the arguments brought up to keep Fortran alive was that you never risked a stack overflow in Fortran; it was safer than stack languages. Besides: Since there were no stack management, the call overhead was reduced.
At least in its first standard version, Ada required recursive functions to be flagged as such in the program text, and that the maximum calling/recursion depth to be statically determinable at compile time, so that the maximum stack requirement can be calculated in advance.
CHILL also required recursive functions to be marked as such, but I am not sure if you were allowed to code an 'uncontrolled' recursion. At least, to manually search for stack overflow problems, you could limit the search to functions marked as recursive.
the C/C++ scoping/life time rules apply to the source code only and how it 'conceptually' is executed, and does not relate to the compiled code and how it actually runs.
So as per the OP
"will allocate memory for an int every frame."
To me that is a question about how the compiler emitted code works and has nothing to do with the spec.
It seems to me to be obviously referring to the stack frame (emitted code.) And for comparison both parts of that are meaningless if the compiler emitted code uses a CPU register.
Compliance for the spec only applies to the 'scope' which means the visibility and the lifetime of the data.
Thus no one can use a compliant compiler and then complain when they attempt to circumvent the scope, for example by using a pointer. Because a compliant compiler can (but is not required) to reuse either a stack frame slot or a CPU register.
It is however possible to use a compliant compiler and deliberately circumvent the scope and it will work. At least for that compiler and that version of the compiler. Might even work in some cases in the same emitted binary and not others depending on how the compiler (not the spec) decides to optimize.
Last Visit: 31-Dec-99 18:00 Last Update: 3-Oct-23 5:09