0

Given I loop the execution of function Foo multiple times:

int Foo(int a)
{
int b = 5;
return a * b;
}

I believe the variable "b" is gets initialized many times (as many times as I initialize function Foo). Assuming I don't want to move "b" outside of the function Foo, do I have to free up the memory claimed by subsequent "b" initializations, or is it done automatically?

Tooa1
  • 23
  • 4
  • 2
    b is created on the stack. as soon as you return it goes away. – Matthew Whited Feb 09 '17 at 20:51
  • 2
    If you think that you need to _manage_ these kind of variables I suggest you to read [Value vs Reference Types](http://www.albahari.com/valuevsreftypes.aspx) and understand the difference between [heap and stack](http://stackoverflow.com/questions/79923/what-and-where-are-the-stack-and-heap) – Steve Feb 09 '17 at 20:54
  • @Dan, I'd rather have a coder on my team who understands the memory impact of his code than one who doesn't care. – hoodaticus Feb 09 '17 at 21:07
  • In this example it's created on the stack. – Matthew Whited Feb 09 '17 at 22:14

1 Answers1

3

Those are integers and could be stored on the stack but not likely in this case. Stack memory does not need to be managed as as soon as the variable is out of scope it is popped off the stack and the memory is freed. Also you rarely have to worry about manually managing memory in .net when you used managed objects (properly).

For more on if these values are actually stored on the stack or not see this answer by Marc Gravell. Also, as pointed in that answer, Eric Lippert a well written article on this (from 2009 but not much has changed).

from Marc Gravell's answer

They sometimes are, but not as:

  • fields on a class
  • captured variables
  • variables in an iterator block
Community
  • 1
  • 1
Igor
  • 60,821
  • 10
  • 100
  • 175
  • 4
    Value types do not necessarily go on the stack. They're stored wherever the data for that variable is stored, which could be in any number of locations, only one of which is the stack. – Servy Feb 09 '17 at 20:53
  • 1
    @Servy - True but in the rather simple example above that would likely be the location where they would be. – Igor Feb 09 '17 at 20:54
  • 2
    @Igor It's rather likely that it *won't* be on the stack here. But even if that were to be true the answer is still wrong, and misleading. – Servy Feb 09 '17 at 20:55
  • In an example this simple I'd expect b to be replaced with the constant 5 and `Foo` inlined. – Lee Feb 09 '17 at 20:55
  • 1
    @Lee - agreed assuming compilation was done with optomization enabled. – Igor Feb 09 '17 at 20:56
  • 1
    @Servy : I am quite confused with your comment. My impression is that value types are stored in stack. so, where could tvalue types stored except stack? – Akash KC Feb 09 '17 at 20:57
  • 1
    @LolCoder아카쉬 They're stored wherever the variable's value is stored, as I said. Some variables are stored on the stack, some will be optimized away entirely (as Lee mentions is likely to be the case here) some will be entirely stored in registers, locals that are closed over, in iterator blocks, async methods, etc. will all be fields of a class, explicit fields of a class will all be where the instances of those objects are (which is the heap) static variables have their own section where they go, fields of large objects would be in the large object heap, etc. – Servy Feb 09 '17 at 20:59
  • 2
    @LolCoder아카쉬: Do you believe that the ints in an `int[]` are all on the stack? Do you believe that boxed ints are on the stack? The idea that value types are stored on the stack is obviously false and I genuinely do not understand why so many people believe it. *Things that are needed for the lifetime of a method activation* are stored on the stack; the stack is the *temporary storage pool*. That has nothing to do with whether a value is an int or a reference to an object. – Eric Lippert Feb 10 '17 at 16:44