1

I encountered the following question in an exam:

When a program calls a function, in which type of data structure is the memory allocated for the variable in that function?

  1. HEAP
  2. QUEUE
  3. LIFO
  4. STACK

According to the test, HEAP is the correct answer, although I selected STACK.

Can someone fantastic person out there please explain why?

Thanks in advance.

trincot
  • 317,000
  • 35
  • 244
  • 286
DawnFreeze
  • 164
  • 1
  • 3
  • 13
  • 5
    [The Stack Is An Implementation Detail, Part One](http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx) and [The Stack Is An Implementation Detail, Part Two](http://blogs.msdn.com/b/ericlippert/archive/2009/05/04/the-stack-is-an-implementation-detail-part-two.aspx) By Eric Lippert – Habib Feb 04 '14 at 20:02
  • 2
    The supposed answer is wrong, basically - in most cases. Although you shouldn't normally care... as per Eric's comment :) – Jon Skeet Feb 04 '14 at 20:02
  • 1
    Interesting post: http://stackoverflow.com/a/14023708/172769 – Luc Morin Feb 04 '14 at 20:04
  • 1
    Unfortunately, whoever created that exam does not appear to know the subject well - judging from the phrasing of their question and their confidence that they know the correct answer to it (especially in an extremely complicated language like C#). An instructor who can't tell the difference between variables and objects is probably not a good instructor for C# or similar programming languages. – Theodoros Chatzigiannakis Feb 04 '14 at 20:20
  • 1
    @DawnFreeze, as currently described, this is a bad question, but it does make me wonder whether there was additional context to the exam question not presented here. – Dan Bryant Feb 04 '14 at 20:27
  • Thanks you for all your replies... @Dan Bryant - There wasnt really any further context to the question, it was part of a Fundamentals exam, with a bunch of random .NET based programming questions. I am glad to read these responses, because this really confused me. Thanks again. – DawnFreeze Feb 04 '14 at 20:31
  • Is that _exactly_ how it was worded because it is unanswerable in the current form since the answer is different between value and reference types. As others have said you shouldn't normally care, but it is a good thing to know for the rare occasions when it does matter. – Yaur Feb 04 '14 at 23:56
  • Yes, that was the exact question. These posts have indeed revealed somehing of a 'bigger picture' to me. It is easy spend alot of energy holding on to concepts that will ultimately prove to be trivial. – DawnFreeze Feb 05 '14 at 00:31

3 Answers3

1

First, C# doesn't have "functions"; it has "methods".

What do you mean by "in which type of data structure is the memory allocated for the variable in that function?"

Nota Bene: Just for the record, "LIFO" is an access strategy (Last-In, First-Out), not a data structure. Normally, one refers to a STACK as a LIFO STACK. But I digress.

The correct answer is, usually, either

  • "it depends", or
  • "both stack and heap"

Slots for local variables (variables that only exist within the context of a method invocation) are allocated within the stack frame for the duration of the method invocation, which is located in the program stack.

If the variable is a reference type, that slot is a reference to the actual object instance, memory for which will be allocated from the heap when/if it is instantiated.

IF the variable is a value type, that slot is [usually, but not always] the object instance itself . . . but that is not a given. Value types can (and are), if need be, allocated on the heap. In which case, the stack frame slot for the variable is, like a value type, a reference to the instance allocated on the heap.

Nicholas Carey
  • 71,308
  • 16
  • 93
  • 135
  • If the variable is a value type then the "slot" is *always* the object itself. That's the *point* of a value type. It's its *definition*, that variables of that type always contain the actual object, whereas for reference types variables of that type always contain a reference to an object stored "elsewhere". Whether a variable of a value type is stored on the stack, heap, or elsewhere, is another matter entirely, and can most certainly vary, but whereever the "slot" is that is allocated for that variable, that is *exactly* where the object's value is stored, else it's not of a value type. – Servy Feb 04 '14 at 20:18
  • 1
    Also, "both stack and heap" isn't quite right. There are other options besides just those two, such as the variable being enregistered. – Servy Feb 04 '14 at 20:19
  • That's not exactly true (leaving out local variables assigned to CPU registers, etc.). Consider `object o = (object)3;`. The value type is boxed and lives on the heap. Or `int[] foo = new int[]{ ... } ;`. That's 100 integers, not boxed, that live solely in the heap. Like I said, "it depends". But more to the point, you shouldn't care. – Nicholas Carey Feb 04 '14 at 20:28
  • Both of those variables are variables of reference types. They are not variables of value types. The fact that the variables do not contain the objects themselves, but rather references to objects that exist elsewhere, is exactly why, by definition, those variables are "reference types" and not "value types". Variables of type `object` are always reference types. Arrays are always reference types. – Servy Feb 04 '14 at 20:29
  • And where do the *integer(s)* contained live? – Nicholas Carey Feb 04 '14 at 20:34
  • That's not relevant to what the question is asking. It's asking about the *variables*, not the values that the variables represent. Having said that, one can say that all reference types in C# will reference values in the heap. The will never reference something on the stack, or in some other location. This is different from pointers (one of the key differences in fact), which *can* reference such locations. – Servy Feb 04 '14 at 20:36
  • I think @Servy is right. Reference types are always on heap while value types can on stack or heap. A local `struct` instance contains a `int[]` and a `int` will be on stack where it contains a int and a reference to `int[]` that on heap. Howerver a local `class` instance with a `int`, that `int` will follow the `class` to be on heap. But value-type can reference something on stack. Am I right? see the new c#7 [ref struct](https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/keywords/ref) – joe Dec 01 '18 at 21:53
  • @joe A variable of a value type doesn't necessarily go on the stack. It could go in a number of different places based on a number of different possibilities. – Servy Dec 03 '18 at 14:31
0

This is a very poorly written question, and I wonder about the abilities of the person who wrote it. As bejger answered, in most languages local variables (and function arguments) are stored on "the stack." In reference languages like C# or Java, objects are stored in "the heap" with a reference to the object (a pointer) stored on the "stack." The question is suspect because it doesn't specify the language or the exact scenario. Also, I wouldn't call the heap and the stack "data structures" at all. They're memory allocation schemes, not data structures in this context.

TypeIA
  • 16,916
  • 1
  • 38
  • 52
  • I'd argue that they are in fact data structures... The stack can be unwound AKA pushed/popped (think: call stack), whereas the heap is randomly placed memory accessed by pointers. – Haney Feb 04 '14 at 20:06
  • 1
    @dvnrrs I think you could have given your comment without making snide remarks about the OP. – Luc Morin Feb 04 '14 at 20:07
  • @mrlucmorin Pardon? I do not follow. – Haney Feb 04 '14 at 20:09
  • @DavidHaney Yes, but the programmer isn't generally concerned with that, the compiler/library writer is. When people talk about data structures and throw out examples like Queues and LIFOs, they're generally talking about constructs that the programmer creates, not what the compiler is doing. I'm assuming that this exam was from a general programming course or something, not a compiler course :) – TypeIA Feb 04 '14 at 20:09
  • 1
    @DavidHaney sorry, got bitten by autocomplete... corrected my mistake. – Luc Morin Feb 04 '14 at 20:10
  • @dvnrrs - I agree, but do not confuse implementation detail with fact. The stack and heap are implementation details of the runtime, however they are also valid data structures. – Haney Feb 04 '14 at 20:10
  • 2
    @mrlucmorin he's not insulting the OP, he's criticizing the author of the OP's quoted question. – Haney Feb 04 '14 at 20:11
  • 3
    @mrlucmorin I wasn't making snide remarks about the OP at all. I was making a comment about the person who wrote the exam question the OP is confused about. And it wasn't meant to be snide, but I do feel that the question is very poorly written and it suggests the author may not be the best instructor. (Of course, everyone makes mistakes.) – TypeIA Feb 04 '14 at 20:12
  • While this does contain useful information, it doesn't appear to provide any sort of answer - make sure to work in an "answer" aspect. – user2864740 Feb 04 '14 at 20:26
-1

Well, local variables and parameters are stored on the stack not on a heap. For local value-types, this means that the value itself is stored on the stack. For local reference-types, only the reference will be on the stack.

Yet to get a more in-depth explanation I recommend to read a very good blog post of Erik Lippert's (who has already pointed to this blog post in the comment): The Stack Is An Implementation Detail, Part One .

Paweł Bejger
  • 6,176
  • 21
  • 26
  • 1
    It depends. A captured local is stored on the heap. – Brian Rasmussen Feb 04 '14 at 20:06
  • 2
    And even if they are conceptually stored in the stack, from the point of view of the IL code, the runtime may end up only ever storing the value in registers, never needing to store it in memory *ever*. – Servy Feb 04 '14 at 20:10
  • And then throw in boxing and unboxing, and it's a whole mess of fun. :) – Haney Feb 04 '14 at 20:12
  • 1
    @DavidHaney Boxing has no affect on where the memory of *the variable* is stored. It may have an effect on where a given instance of a type is stored, which may or may not be the value of that variable, or be what the reference that that variable contains references, which is not what the question is asking. – Servy Feb 04 '14 at 20:13
  • @Servy well said. By the memory of the variable, you mean even boxed a pointer to the instance would remain on the stack, yes? – Haney Feb 04 '14 at 20:13
  • 1
    @DavidHaney Well, it might not be on the stack, but if it's not, it's because the variable is closed over, or in an iterator block, etc. The fact that a variable is a boxed value type, or a reference type, or a value type, has no effect on where that variable's memory is stored, only where the object that the variable "represents" may be stored. – Servy Feb 04 '14 at 20:23