For loop
-
If I have a for loop, the program will allocate memory for an int every frame. When the for loop is done will the memory be released or will it result in garbage that piles up every frame. int main() { for(int anint = 0; anint < 100; anint++) { } }
It's been the same since C99 [C99 block scope](https://www.google.com/search?q=c99+block+scope) [C++ block scope](https://en.cppreference.com/w/cpp/language/scope)
-
This memory is allocated on the stack and will be "released" after the loop finishes.
The program knows I don’t need the integer after the loop is done, thanks.
-
It's been the same since C99 [C99 block scope](https://www.google.com/search?q=c99+block+scope) [C++ block scope](https://en.cppreference.com/w/cpp/language/scope)
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 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.
jschell wrote:
C, so before C++, would limit the scope to the method.
No, C89, C90 through until C98 had method scope.
jschell wrote:
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.
The ISO standards are listed at the bottom of this page. Could you point out what you are referring to? I see what you are saying now. You are describing old C89 rules. Are you an embedded C programmer? Those scope rules were changed way back in 1999. Yeah, modern compilers don't have method scope at all anymore. Some embedded compilers still do C89
-
If I have a for loop, the program will allocate memory for an int every frame. When the for loop is done will the memory be released or will it result in garbage that piles up every frame. int main() { for(int anint = 0; anint < 100; anint++) { } }
Calin Negru wrote:
the program will allocate memory for an int every frame.
No, it does not. An int is a "value type", and value types are usually allocated on the stack, not the heap. Also, in your example, the
anintvariable is only allocated (or "pushed" onto the stack once, upon execution of the loop initializer. The value in that stack location is changed on every iteration of the loop. Once the loop is complete, that variable is popped off the stack and will no longer exist. Of course, all of this is a bit generalized and is not accurate in all cases. It is possible to allocate a value type on the heap, generally called "boxing".Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave Kreskowiak -
Calin Negru wrote:
the program will allocate memory for an int every frame.
No, it does not. An int is a "value type", and value types are usually allocated on the stack, not the heap. Also, in your example, the
anintvariable is only allocated (or "pushed" onto the stack once, upon execution of the loop initializer. The value in that stack location is changed on every iteration of the loop. Once the loop is complete, that variable is popped off the stack and will no longer exist. Of course, all of this is a bit generalized and is not accurate in all cases. It is possible to allocate a value type on the heap, generally called "boxing".Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakThank you.
-
jschell wrote:
C, so before C++, would limit the scope to the method.
No, C89, C90 through until C98 had method scope.
jschell wrote:
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.
The ISO standards are listed at the bottom of this page. Could you point out what you are referring to? I see what you are saying now. You are describing old C89 rules. Are you an embedded C programmer? Those scope rules were changed way back in 1999. Yeah, modern compilers don't have method scope at all anymore. Some embedded compilers still do C89
Randor wrote:
Could you point out what you are referring to?
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.
-
Randor wrote:
Could you point out what you are referring to?
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.
The C99 standard is here: [C99 Standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Scope starts at 6.2.1 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.](https://nuwen.net/stl.html) I always thought that was funny.
-
If I have a for loop, the program will allocate memory for an int every frame. When the for loop is done will the memory be released or will it result in garbage that piles up every frame. int main() { for(int anint = 0; anint < 100; anint++) { } }
The typical way for functions to work is allocating whatever stack space they need *once* in the prologue. But there's no need for `anint` to be in memory here. Or to exist at all for that matter, since the loop trivially doesn't do anything and can be skipped. MSVC compiles this function [like this](https://godbolt.org/z/EGvPM3Ez3), `anint` isn't anywhere, not in memory, not in a register, just gone. If it *was* going to be in memory, then only one instance of it needs to exist, so that's what happens. Or should happen anyway. If a compiler individually allocated separate copies of that variable for each iteration, I would file a bug report.
-
The typical way for functions to work is allocating whatever stack space they need *once* in the prologue. But there's no need for `anint` to be in memory here. Or to exist at all for that matter, since the loop trivially doesn't do anything and can be skipped. MSVC compiles this function [like this](https://godbolt.org/z/EGvPM3Ez3), `anint` isn't anywhere, not in memory, not in a register, just gone. If it *was* going to be in memory, then only one instance of it needs to exist, so that's what happens. Or should happen anyway. If a compiler individually allocated separate copies of that variable for each iteration, I would file a bug report.
Thanks for sharing
-
The C99 standard is here: [C99 Standard](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n1256.pdf) Scope starts at 6.2.1 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.](https://nuwen.net/stl.html) I always thought that was funny.
Randor wrote:
6.2.4 Storage durations of objects
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.
-
Randor wrote:
6.2.4 Storage durations of objects
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.
-
Calin Negru wrote:
the program will allocate memory for an int every frame.
No, it does not. An int is a "value type", and value types are usually allocated on the stack, not the heap. Also, in your example, the
anintvariable is only allocated (or "pushed" onto the stack once, upon execution of the loop initializer. The value in that stack location is changed on every iteration of the loop. Once the loop is complete, that variable is popped off the stack and will no longer exist. Of course, all of this is a bit generalized and is not accurate in all cases. It is possible to allocate a value type on the heap, generally called "boxing".Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles.
Dave KreskowiakDave Kreskowiak wrote:
It is possible to allocate a value type on the heap, generally called "boxing".
Are you referring to managed code or native code with this statement?
The difficult we do right away... ...the impossible takes slightly longer.
-
Dave Kreskowiak wrote:
It is possible to allocate a value type on the heap, generally called "boxing".
Are you referring to managed code or native code with this statement?
The difficult we do right away... ...the impossible takes slightly longer.
Managed. In my illness induced stupor, I thought we were in the C# forum.
Asking questions is a skill CodeProject Forum Guidelines Google: C# How to debug code Seriously, go read these articles. Dave Kreskowiak
-
Randor wrote:
6.2.4 Storage durations of objects
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.
I'm still not clear about this. 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?
-
I'm still not clear about this. 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?
trønderen wrote:
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. The spec is just asserting that they are not 'available' outside the block. In reality, in terms of the compiler emitted code? Probably. 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;
doit(C);}
-
trønderen wrote:
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. The spec is just asserting that they are not 'available' outside the block. In reality, in terms of the compiler emitted code? Probably. 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;
doit(C);}
jschell wrote:
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; doit(C); }
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.
-
I'm still not clear about this. 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?
To add to what jschell said about the spec, I'd point out that modern compilers are surprisingly good at code analysis. I often run into situations where I ask the debugger for a variable value on an optimized build and get a message similar to "variable optimized away". So the compiler only needs to produce code as if a variable exists. If it can deduce the value of the variable for its lifetime, it doesn't need to actually provide storage space for it. There's obviously things you might do that would require there actually be space for it on the stack, like passing its address to a function, for example.
Keep Calm and Carry On
-
trønderen wrote:
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. The spec is just asserting that they are not 'available' outside the block. In reality, in terms of the compiler emitted code? Probably. 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;
doit(C);}
trønderen wrote:
If variables X and Y are defined in a block, must they both be available throughout the lifetime of that block?
jschell wrote:
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.
-
To add to what jschell said about the spec, I'd point out that modern compilers are surprisingly good at code analysis. I often run into situations where I ask the debugger for a variable value on an optimized build and get a message similar to "variable optimized away". So the compiler only needs to produce code as if a variable exists. If it can deduce the value of the variable for its lifetime, it doesn't need to actually provide storage space for it. There's obviously things you might do that would require there actually be space for it on the stack, like passing its address to a function, for example.
Keep Calm and Carry On
