Programming Languages Series
I will write a few articles about the Programming Languages, in order to fix some misleading ideas, and misunderstanding.
- Episode 1 – Expression Evaluation.
- Episode 2 – Memory Management in .NET.
Episode 2 – Memory Management
There are many myths about .NET Memory Management, such as:
- Value types are allocated on the Stack.
- Everything is an object.
- There is no Stack in .NET!
.NET Memory Managed by Microsoft .NET Common Language Runtime, Garbage Collection in the Microsoft .NET Common Language Runtime is the responsible to track the memory usage and knowing when to free memory.
Usually when we speak about data types we maintain two primary categories: Value Type, and Reference Type.
Value Types: Actually I found that MSDN Documentation, most of .NET books (VB, C Sharp), and some of C++ books use incorrect definition for value type. So what is the correct definition?
“Value Type is a data type that can exist outside dynamic memory allocation. Unlike reference types, value types can be directly embedded into composite objects.” This definition is extremely abstract and true, so let’s make it clear: The Value Type can exist into the Stack, or into the Heap directly embedded into composite objects.
But there are another right way to think about Value Types, is think about it by-design semantic meaning, instead of the implementation details. The semantic meaning of ‘Value Type’ is: The value type is always copied ‘by value’ however where they exists Stack or Heap.
When Value Type is allocated in Stack, or in Heap? Simply when you create a method scope Value Type it will allocate in Stack, but if you create a value type class field this member will allocate in heap however if it’s Value Type of Reference Type. But the different is the Value Type can directly embedded into composite object, but if the member is reference type such as string the object will content only reference to the string object.
I hope now it’s clear that Value Type could exist into Heap or Stack depend on scope, Also the Value Types is always copied by value, which means when you passing a value type to method it’s will copied by value, except if you pass it by reference.
Everything is object! Some people try to convince themselves that everything in .NET is an object, even the value type. So let’s see what is object first ?
“In computer science, an object, in the domain of object-oriented programming, usually means a compilation of attributes (object elements) and behaviors (methods) encapsulating an entity. However, outside the object-oriented programming domain, the word object may simply mean any entity that can be manipulated by the commands of a programming language, such as a value, variable, function, or data structure” – Source: Wikipedia
So what they means by “Everything is Object” ? Every type is derived from a single root (System.Object). Which means, that every value can be implicitly casted to System.Object. More precisely, this means that every value is representable as an instance of System.Object.
Actually not everything is derived from System.Object for example int*, which means you can’t pass int* to method that accept System.Object, also you can’t call GetHashCode(), or ToString() methods in such types. What about Value Types? A lot of people today wonders why and how the value types derived from System.Object? and this actually lead some to weird conclusions. So the simple answer is:
“It’s will be better to think about the value types by design semantic meaning, instead of the implementation details. The semantic meaning of ‘Value Type’ is: The value type is always copied ‘by value’ however where they exists Stack or Heap.”
I know this answer will not satisfy anyone. Actually the Value-Types that derived from System.ValueType are not object by the object definition but every value type can casted implicitly to System.Object.