Memory allocation for variable declared in class_问答_开发者

As Value type variable allocates memory in Stack whereas Reference type allocates it in Heap.

So how the memory allocated when a value type variable (e.g. int i = 4;) is declared in the reference type (e.g. in a class).开发者_运维知识库

How the overall memory allocation works in .NET for value type & reference type, and also value type inside the scope of reference type.

Please explain it or provide any links regarding that.

A value type variable allocates memory on the stack whereas a reference type allocates it in heap.

No, that statement is completely wrong. Lots of people believe that, but it is obviously false, as you have discovered.

How is the memory allocated when a value type variable int i = 4; is declared as a field of a reference type?

Clearly you know why your first statement is completely wrong. The integer field of the class cannot be allocated on the stack because the object might live longer than the stack frame.

To understand what is really going on, first you have to realize that there are three kinds of things:

value types
references
instances of reference type

References and instances of reference type are completely different, just as a piece of paper containing my address and my actual house are completely different.

The next thing you have to understand is that there are two kinds of storage: long-term and temporary storage. Long-term storage is usually called "the heap", but I prefer to think of it simply as long-term storage. Temporary storage is usually called "the stack" but that is also misleading because of course there could be multiple stacks, there could be temporaries stored in registers, and so on.

An instance of a reference type occupies memory in the long-term storage. (Sometimes it would be possible to determine that an instance of a reference type is short-lived, and put it in temporary storage, but we do not do this optimization in practice.)

A variable is a storage location which stores either a value of value type or a reference.

Where the storage location of the variable is allocated depends on the lifetime of the variable. If the variable is a local variable known to be of short lifetime, it is allocated from the temporary storage pool. If the variable is known to be of long lifetime (because, say, it is an outer variable of a closure) then it is allocated off the long-term storage pool.

If the variable is a field of a class, we already know that its storage comes from the long-term pool. If the variable is a field of a value type, that value type inhabits storage somewhere; the field inhabits the same storage.

If the variable is an array element, it is allocated off the long-term storage pool; arrays are instances of reference type.

The key to getting your understanding correct is to simply stop believing the myth that whether a variable is of reference or value type affects where the storage is allocated. That is not true and has never been true, and doesn't even make any sense.

The only thing that affects where a variable is stored is how long does the variable live for. Short-lived variables are allocated off the temporary pool -- the stack, or registers -- and long-lived variables are allocated off the long-term storage pool -- the heap.

This is why Eric Lippert reminds us that the stack is an implementation detail.

When an instance of a value type is a member of a reference type yes, it is stored on the managed heap along with the parent object. It's a good question and something you should understand, just not something that should drive your design in most scenarios.

structs should be small, simple data types that are relatively cheap to create and pass around. Reference types are your complex types, require only a copy of the reference to pass to a method, but of course come with some baggage due to being allocated on the heap. Here is a good follow up post regarding the implications of stack versus heap allocations.

There are plenty of references out there which explain the performance implications of value types versus reference types. You should learn all about it and also understand that, most of the time, it is a semantic decision, not a performance decision.