c# Value types and reference types

 
Value types vs reference types: The main differences in the Swift 
 
May be this topic is one the most confusing part in C# and a quick stackoverflow search would return a pretty huge amount of Q&A on this. This writing would be more for my reference as I myself getting confused with this topic overtime and every time I need to do lot of search to get the exact stuffs. So I will consolidate the abstracts here. I will keep the references in the footer so the reader can have a in-depth read on the same.

Value Types

The typical convention is “Value types always goes to stack”. This is an incorrect statement and the statement should be "value types can be stored on the stack and the heap"
  • There are three kinds of storage locations: stack locations, heap locations, and registers.
  • Long-lived objects are always heap locations.
  • Short-lived objects are always stack locations or registers.
References and instances of value types are essentially the same thing as far as their storage is concerned; they go on either the stack, in registers, or the heap depending on whether the storage of the value needs to be short-lived or long-lived.

Why short-lived value types are stored in stack

The stack is a "FILO" (first in, last out) data structure, that is managed and optimized by the CPU quite closely. Since CPU organizes stack memory so efficiently, reading from and writing to stack variables is very fast. Every time a function declares a new variable, it is "pushed" onto the stack. Then every time a function exits, all of the variables pushed onto the stack by that function, are freed (that is to say, they are deleted). Once a stack variable is freed, that region of memory becomes available for other stack variables. Since stack is handled by CPU, .Net Garbage collector need not to take care of stack allocation and deallocation.

Reference Types

The storage locations of instances of reference types are always treated as though they are long-lived, even if they are provably short-lived. Therefore they always go on the heap.
We are taught for years, reference type object will hold an address, that is the physical memory address where object is stored on heap. This is absolutely wrong. Reference type variable will never hold the exact physical address of the memory location on heap. It will hold a reference and this reference is not an address, a reference is something like "a reference is a small chunk of data which contains information used by the CLR to find out the actual physical address of the object in the heap." 
Why references, not pointers
As per Eric Lippert, “We also want to avoid some of the optimization nightmares that languages with pointers have. Languages with heavy use of pointers have a hard time doing garbage collection, optimizations, and so on, because it is infeasible to guarantee that no one has an interior pointer to an object, and therefore the object must remain alive and immobile.

Why reference types are stored in heap

Unlike the stack, the heap does not have size restrictions on object size (apart from the physical limitations of the computer)
Reference type always goes to heap. Reference type object never holds the exact physical address of the storage location on heap. Reference is not an address. Reference and pointer is entirely different entities.

References

  1. The Truth about value types.
  2. References are not addresses.
  3. Jon Skeet on value type and ref type
  4. .NET: Type Fundamentals – msdn article
  5. What is Stack and Heap
  6. StackOverflow Link1
  7. StackOverflow Link2
  8. StackOverflow Link3
Disclaimer: I have shamelessly copied sentences and words from the blogs put in references.

Comments

Popular posts from this blog

Consume Antimalware Scan Interface (AMSI) from C#

Munnar Diaries [Part 1] - Backpacking to Munnar and spectacular Vattavada village

Missing her badly. Need to date her once more at least.. ;)