11

When the memory is allocated to a function. For example: 

int doubleMe(int smthng){ 
int dbl = 2*smthng; //line 2
return dbl; 
} 

void main(){ 
int var; 
printf("The double of var is: %d",doubleMe(var)); //line 8
}

When is memory allocated to variable dbl?

  • when is defined (line 2) (compile time)
  • or when function is called (line 8)(run time)

I believe it is allocated when function is called(run-time) in stack. And freed when function exits, is it? Would be great if someone could please explain it better.

This question looks similar but not quite!

Anil Bhaskar
  • 3,718
  • 4
  • 33
  • 51
  • 2
    So you think the compiler never compiles your function?? If it does than isn't the same holds good for the function also? main() is also a function btw – Gopi Mar 09 '15 at 14:01
  • That's usually an implementation detail. But local non-static/non-const variables are usually created via stack when the function gets called. – Zeta Mar 09 '15 at 14:01
  • but still @Gopi has a point – Anil Bhaskar Mar 09 '15 at 14:05

4 Answers4

9

The compiler generates object code of a function when it is defined. The generated code contains instructions to allocate memory in the stack for function local variables or it can use registers to accomodate them.

Where a function is called the compiler generates object code of the function call and corresponding instructions to push arguments on the stack. At this point the compiler may not to know how the function is defined and whether it is defined because its definition can be in some other module or library.

Take into account that the compiler may inline functions even if you yourself do not use function specifier inline. In this case it will place the function definition in the point where the function is called.

Vlad from Moscow
  • 301,070
  • 26
  • 186
  • 335
  • 1
    In olden times that was the case. However, particularly with x86_64, the compiler is as likely to use registers to hold the argument and the local variable. – JeremyP Mar 09 '15 at 14:09
  • @JeremyP It was also in olden times. Some arguments especially of fundamentals types can be passed through registers. However this is behind the scene. – Vlad from Moscow Mar 09 '15 at 14:10
  • Thanks @Vlad. The generated code contains instruction _for everything what my program is!_ doesn't it? So simply it allocates memory while a function is called. Or you meant something else? – Anil Bhaskar Mar 09 '15 at 14:12
  • You have a mental model of how the program works -- in this case your model tells you that space is reserved on the stack for auto variables as the processor enters the function. The compiler is allowed to implement this any way it wants to as long as the results match your expectations. In other words, the only way to find out is to look at the generated machine code -- and even that may change depending on different compile flags, or other factors. – Dale Wilson Mar 09 '15 at 14:14
  • Thank you @VladfromMoscow. I had the same question because [this documentation](https://www.ibm.com/docs/en/xl-c-and-cpp-aix/16.1?topic=functions-function-declarations-definitions) says that function definitions do result in storage being allocated for the function, which confuses me. Might the author just be referring to the memory that holds the object code for the function? – user51462 Aug 06 '23 at 23:56
  • @user51462 I think he means the memory where the object code of the function body is stored. – Vlad from Moscow Aug 07 '23 at 08:25
4

Memory is allocated to variable dbl(or var) at compile time in the stack memory

Not correct, it is allocated in run-time, just as all other stack variables. That's the whole point of using a stack. It is allocated when your function is called, in run-time.

I believe it is allocated when function is called. And freed when function exits, is it?

Yes.

Lundin
  • 195,001
  • 40
  • 254
  • 396
3

Regarding your statement: Memory is allocated to variable dbl(or var) at compile time
No, The instructions to allocate memory are created at compile time.
Memory is not allocated until that function is executed.
Memory created inside a function is an example of local scope memory. if it is created on the stack, it will be released upon leaving the scope in which it was created. If it was created on the heap (i.e. created using [m/c/re]alloc() functions) it will not be released (or more accurately, made available as described here) until free() is called, or at program exit.

Later, you state:
I believe it is allocated when function is called. And freed when function exits.
This statement is true, but this all happens at run-time only. Not at compile-time.

For global scope memory, stack memory is created when the program is executed, and is not released until the program ends. Again, for heap memory , it will be released upon calling free(), or at program exit.

ryyker
  • 22,849
  • 3
  • 43
  • 87
  • heap memory is not necessarily freed at program exit, it depends on the operating system, however modern operating systems do that. win98 is a good example which does't free at program exit – Anil Bhaskar Mar 09 '15 at 14:49
  • 1
    @AnilBhaskar - The only time I am aware that memory is not released for an executable, even in Windows 98, is when running in a debug environment. Even when execution stops, many time the debug environment will continue to run, and if memory was not freed in the target it remains until the debug environment is terminated. Other than that, I have not experienced what you describe. – ryyker Mar 09 '15 at 14:49
  • 1
    thanks @ryyker +1, happy to know that. still it is good to free dynamic allocated memory always. – Anil Bhaskar Mar 09 '15 at 14:57
0

It's not allocated during compilation at all, but at runtime.

When the function is called during execution, either space will be reserved for it in memory (in approximately 100% of current C++ implementations, "on the stack") or it will reside in a register.
If it's not in a register, the space is freed when the function returns.

The compiler produces code that will perform the runtime allocation, if there is any.

molbdnilo
  • 64,751
  • 3
  • 43
  • 82