In C, are variables located in the stack recycled/freed when they are no longer needed? I suppose that this depends on the compiler, but does anyone know if GCC does this?
To be a little clearer, let's say I have these two translation units...
main.c/.h
settings.c/.h
main() calls the function get_settings() (located in settings.c) which will fill the variables (located in main.c) with data read from a file and then returns.
Since there is no longer any purpose for the staic variables declared in settings.c, are they freed once get_settings() returns?
Name:
Anonymous2009-10-31 1:50
As far as I know, any variable which is declared without using a pointer will be freed when that variable loses scope.
Variables declared using a pointer must be explicitly deleted or they will remain in memory.
Name:
Anonymous2009-10-31 2:00
>As far as I know, any variable which is declared without using a pointer will be freed when that variable loses scope.
How about variables declared at the top of files (outside the scope of functions) or better known as global variables?
When declared as static, do they consider the translation unit the scope?
>>3
Anything that is not malloc'd, calloc'd, realloc'd, or brk (or equivalent)'d is on the heap. Everything else is on the stack and is freed automatically when it loses scope. For variables at the top of files I believe they are on the stack for the entirety of execution.
Local variables of limited extent(scope) are subject to register allocation in most sane compilers, and when a register or stack location which was asseigned to a variable which is no longer needed, that space can be reallocated to another variable. Any serious compiler does this, and I've examined plenty of disassemblies of compiled C programs which show the same register used for the different variables in different places in the function, this also applies to locations on the stack.
While the ways in which each compiler does register allocation may be different, you should know that once a variable is out of scope, its location in memory/regs may become used by something else.
Name:
Anonymous2009-10-31 2:54
>>4
No. File-local variables (i.e. variables in the global scrope but declared static) and global variables are just stored as part of the executable which is mapped into the process's address space by the linker.
THERE ARE FUCKING 8 RESPONSES THAT ARE SERIOUS AND NOT ONE IS RIGHT? HOLY SHIT! At least troll him.
Static means the variable is static. It will never move or go away. It will last the entire program.
Now that you have your answer, please respond with sage!
Name:
Anonymous2009-10-31 3:20
>>6
I see, but is there any way I can tell a compiler that a function (or a whole translation unit) will never be called again so its memory can be reused for something else?
>>10
You'll have to consult your compiler's documentation for that.
Some compilers provide special declarations for such things, but first it might be better to just let the compiler perform register allocation by itself. What I said applies to variables, but you seem to mention functions. Functions are static pieces of code, and unless you're dynamically compiling function objects (for example Common Lisp has this, as well as some of the popular virtual machine based JIT engines do, but in less documented ways) and those function objects are treated as regular data that can be deallocated or garbage collected, then no. Unless you plan on allocating the code for your function dynamically and writing it there then freeing it, however for most normal C programs, code is allocated statically in the code section of your executable and stays there for the entire duration of the program. You could of course remove the code contained the function, but there is little use for doing that, as the space might not be easy to be reused for other things. The only reason people even do that is for crappy anti-reverse engineering tricks, which are way too futile.
>>10
What are you writing, and what are you writing it for. You honestly should not be worrying about such things for 99% of programs. You either have to be writing something that is very memory expensive, or on a arch that has a very small amount of memory and doesn't mind the overhead of dynamically allocating program memory.
Name:
Anonymous2009-10-31 4:31
>>7,11 register allocation bullshit
Is this even related to this thread or is it just your way of saying "I haven't read SICP"? Registers have no fucking relation to the discussion.
>>8 File-local variables (i.e. variables in the global scrope but declared static) and global variables are just stored as part of the executable which is mapped into the process's address space by the linker.
One of the less retarded replies in this thread.
OP, use locals instead of statics. Why would you even need statics in your settings code if you call it just once? If the problem is that multiple functions need to access the data, then make it a struct and pass it around via pointer. Then you can free it when you're done.
Why aren't your variables in get_settings() in the first place?
>>13 Is this even related to this thread or is it just your way of saying "I haven't read SICP"? Registers have no fucking relation to the discussion.
Considering the question is about “freeing variables”, it's pretty fucking related that variables are likely not to exist anywhere that could even be freed.
>>13 File-local variables (i.e. variables in the global scrope but declared static) and global variables are just stored as part of the executable which is mapped into the process's address space by the linker. One of the less retarded replies in this thread.
This seems wrong. Why would they be stored in the executable if the values are not necessarily known at compile time? Not only that, but what if the size of the object changes, for example, if your global variable refers to a dynamic array?
How much you know about programming is inversely relational to how much you talk about programming on /prog/. This thread is a GREAT example of that!
Name:
Anonymous2009-10-31 15:23
>>19
You could at least explain what's wrong with what I said in >>18. I don't have much experience in C, so if I'm wrong, I'd like to know why.
Name:
Anonymous2009-10-31 15:45
>>18
Please give a short code snippet that outlines a case that you don't understand. For the global variable referring to a dynamic array, I'm assuming you're talking about a global pointer that points to some malloced chunk of memory. In that case you're storing a single pointer in some uninitialized region (this is typically called the bss section) that is allocated (well, mapped in-- it'll likely be demand allocated) along with the rest of the bss section by the run-time linker on program load. Once your program starts running you set the value of the pointer with a pointer to a location in the heap given to you by malloc. Easy.
This seems wrong. Why would they be stored in the executable if the values are not necessarily known at compile time?
The value isn't stored in the executable, but space is reserved for the value. if the size of the object changes
You recompile if your global variable refers to a dynamic array?
The it would be a pointer which always talks 1 word of memory and the dynamic array would be on the heap
--
~This post has not been fact checked due to laziness, and if it's wrong then correct me and stop whining
1. The values aren't stored in the executable, but instead space would be reserved.
2. If a static object changed you would need to recompile it anyway
3.
Name:
Anonymous2009-10-31 15:46
>>21 >>18 is full of shit. The values ARE known at compile time. At least for static globals.
>>23 The value isn't stored in the executable, but space is reserved for the value.
It's stored if it has an initializer.
Name:
Anonymous2009-10-31 16:10
Isn't it inefficient in terms of space to store initialized static constants in the executable? They could potentially be quite large, and that extra space is basically wasted on every download of your executable file.
>>26 if you want to get more people visiting this board
That's a big if ;)
I'd settle for a 10% reduction in the number of visitors in a bid to rid us of the /pr/ quality threads
It's stored if it has an initializer.
Of course, but I took it that everyone would have known that. I guess I was a little naive
>>28
You store the information in program memory and not volatile memory. That's the point. You sacrifice executable size to decrease the amount of memory required at runtime.
>>31
They end up to be the same thing.
static char[] hello = "Hello!\n"
...
char[] greetings = hello;
and
char[] greetings = "Hello!\n"
Will both allocate static memory for Hello and both reference it in the assignment.
I don't know if the right answer is here or not, I got too fed up reading bullshit to care?: there are no static variables on the stack. All static variables are on the heap and are memory resident for the life of the program. Some compilers may support hints to free the data, but it isn't standard C.
I've examined plenty of disassemblies of compiled C programs which show the same register used for the different variables in different places in the function.