Boxing/Unboxing outside of local scope context

Boxing/Unboxing outside of local scope context - c#

It took me ages to understand that boxing/unboxing isn't a process of copying variable ['s value] from stack to heap but just the process of conversion between value<->reference. All of this because all the examples I saw were like:
int i = 12;
object o = i;
int j = (int)o;
Accompanied by a terrible graphs (in many different examples I saw they are the same) that looked like this:
which lead me to the wrong conclusion that boxing is the process of moving from stack to heap with value->reference conversion happening (and vice versa).
Now I understand it just the conversion process, itself but there are few nuances I need in-depth help with:
1. How does it looks in terms of memory schematics when boxing/unboxing happens with instance variables/class field?
By default, all these variables are already allocated in heap. Any examples of boxing in this scope and how does it behave? No need to draw it if you dont want, written explanation will do.
2. What happens here, for example:
int i = 12;
object o = 12; // boxing? if so - why?
int i = (int)o; // unboxing?
int k = (int)o; // Same?
3. If boxing/unboxing considered "bad" in terms of memory/performance - how do you handle it in cases where you cant do that? For example:
int i = 10;
ArrayList arrlst = new ArrayList();
arrlst.Add(i);
int j = (int)arrlst[0];
What the proper solution here besides "use generics" (non-applicable case, for example).

Original Answer
Boxing/Unboxing is not moving to and from the heap, but about indirection. When the variable gets boxed what you get is a new object (ok, that is in heap, that is an implementation detail) that has a copy of the value.
Now, you take an the object and read one of its fields... what happens? You get a value. The implementation detail is that it is loaded in the stack[*] That value you get can be boxed (you can create a new object that holds a reference to it).
[*]: You would then, for example, call a method (or an operator) which will read its parameters from the stack (The semantics in MSIL are stack manipulation).
By the way, when you get the field and box it, what is in the box is a copy. Think about it, what you boxed came from the stack (you first copy it from the heap to the stack, then box it. At least that is the semantics in MSIL). Example:
void Main()
{
var t = new test();
t.boxme = 1;
object box = t.boxme;
t.boxme = 2;
Console.WriteLine(box); // outputs 1
}
class test
{
public int boxme;
}
Tested on LINQPad.
Extended Answer
Here I will go over the points in the edited question...
1. How does it looks in terms of memory schematics when boxing/unboxing happens with instance variables/class field?
By default, all these variables are already allocated in heap. Any examples of boxing in this scope and how does it behave? No need to draw it if you dont want, written explanation will do.
I get you want an explanation of how boxing works on an instance field. Since the code above demonstrates a use of box on an instance field, I will go over that code.
Before diving in the code I want to mention that I use the word "stack" because - as I said in the original answer - that is the semantics of the language. Yet, it does not have to be a literal stack in practice. The jitter will very likely optimize the code to take advantage of CPU registers. Therefore, when you see that I say that we put things in the stack to take them out right away... yeah, the jitter will probably use a register there. In fact, we will be placing some things on the stack repeatedly; the jitter may decide that it is worth to reuse a register for those things.
First off, we are using a very simple, not practical class test with a single field boxme:
class test
{
public int boxme;
}
The only other thing I have to say about this class is remind you that the compiler will generate a constructor, which takes no parameters. With that in mind, let us go over the code in Main line by line...
var t = new test();
This line does two operations:
Call the constructor of the class test. It will create a new object on the heap and push a reference to it on the stack.
Set the local variable t to what we pop from the stack.
t.boxme = 1;
This line does three operations:
Push the value of the local variable t on top of the stack.
Push the value 1 on top of the stack.
Set the field boxme to a value popped from the stack (1) of an object to which we pop a reference from the stack.
object box = t.boxme;
As you may guess, this line is what we are for here. It does four operations total:
Push the value of the local variable t on top of the stack.
Push the value of the field boxme (of an object to which pop a reference from the stack) on top of the stack.
BOX: pop from the stack, copy the value (and the fact that it is an int) to a new object (created in the heap), push the reference to it on the stack.
Set the local variable box to what we pop from the stack.
t.boxme = 2;
Esentially the same as t.boxme = 1; but we push 2 instead of 1.
Console.WriteLine(box);
Push the value of the local variable box on top of the stack.
Call the method System.Console.WriteLine with whatever we pop from the stack as parameter.
The user sees "1".
2. What happens here, for example:
int i = 12;
object o = 12; // boxing? if so - why?
int i = (int)o; // unboxing?
int k = (int)o; // Same?
Yay, more code...
int i = 12;
Push the value 12 on top of the stack.
Set the local variable i to what we pop from the stack.
No surprises so far.
object o = 12; // boxing? if so - why?
Yes, boxing.
Push the value 12 on top of the stack.
BOX: pop from the stack, copy the value (and the fact that it is an int) to a new object (created in the heap), push the reference to it on the stack.
Set the local variable o to what we pop from the stack.
Why? Because the 32 bits which make the int look nothing like a reference type. If you want a reference type with the value of an int you need to put the value of int somewhere it can be referenced (put it on the heap) and then you can have your object.
int i = (int)o; // unboxing?
A local variable named 'i' is already defined in this scope
I think you mean:
i = (int)o; // unboxing?
Yes, unboxing.
Push the value of the local variable o on the top of the stack.
Unbox: read the value of the object we pop from the stack, and push that value on the stack.
Set the local variable i to what we pop from the stack.
int k = (int)o; // Same?
Yes. Just a different local variable.
3. If boxing/unboxing considered "bad" in terms of memory/performance - how do you handle it in cases where you cant do that? For example:
int i = 10;
ArrayList arrlst = new ArrayList();
arrlst.Add(i);
int j = (int)arrlst[0];
1. Use generics
int i = 10;
var arrlst = new List<T>();
arrlst.Add(i);
int j = arrlst[0];
I have to admit. Sometimes use generics is not the answer.
2. Use ref
C# 7.0 has ref return and locals should cover some cases were we needed boxing/unboxing in the past.
By using ref, what you pass is a reference to the value that is stored in stack. Since the idea of ref is that you can modify the original, using box, (copying the value to the heap) would defy its purpose.
3. Keep an eye on box lifespan
You may try to reuse your references instead of unnecessarily boxing the same value multiple times. That could help to keep the number of boxes low, and the garbage collector will pick on the fact that these are long-lived boxes and check them less often.
On the other hand, the garbage collector will deal very efficiently with short-lived boxes. Thus, if you cannot avoid making a lot of boxing/unboxing, try to make the boxes short lived.
4. Try using reference types
If you are having, performance problems because you have many long-lived boxes... you probably need to make some classes. If you are using reference types to begin with, there is no need to box them.
Although that can be problematic if you need structs for interop... hmm... probably not what you are looking for, but have a look at ref struct. Span<T> et. al. can save you allocations in other ways.
5. Let it be
If you cannot do it without boxing, you cannot do it without boxing.
For example, if you need a generic container that makes atomic operations on the members of the generic type... but you also need to allow the generic type to be a value type... what do you do then? Well, you got to initialize the container with the type object when you need to store some not atomic value type.
No, ref will not save you in that case, because ref does not guarantee atomicity.
Instead of working harder in getting a performance gain from optimizing the use of boxing/unboxing... look for other ways to improve the performance. For example, that generic container I was talking about can be expensive, but if it allows you to parallelize some algorithm and that gives you a performance boost greater than that cost, then it is justified.

Related

How does C# LINQ change the data source and how do I prevent it? [duplicate]

Some guy asked me this question couple of months ago and I couldn't explain it in detail. What is the difference between a reference type and a value type in C#?
I know that value types are int, bool, float, etc and reference types are delegate, interface, etc. Or is this wrong, too?
Can you explain it to me in a professional way?

Your examples are a little odd because while int, bool and float are specific types, interfaces and delegates are kinds of type - just like struct and enum are kinds of value types.
I've written an explanation of reference types and value types in this article. I'd be happy to expand on any bits which you find confusing.
The "TL;DR" version is to think of what the value of a variable/expression of a particular type is. For a value type, the value is the information itself. For a reference type, the value is a reference which may be null or may be a way of navigating to an object containing the information.
For example, think of a variable as like a piece of paper. It could have the value "5" or "false" written on it, but it couldn't have my house... it would have to have directions to my house. Those directions are the equivalent of a reference. In particular, two people could have different pieces of paper containing the same directions to my house - and if one person followed those directions and painted my house red, then the second person would see that change too. If they both just had separate pictures of my house on the paper, then one person colouring their paper wouldn't change the other person's paper at all.

Value type:
Holds some value not memory addresses
Example:
Struct
Storage:
TL;DR: A variable's value is stored wherever it is decleared. Local variables live on the stack for example, but when declared inside a class as a member it lives on the heap tightly coupled with the class it is declared in.
Longer: Thus value types are stored wherever they are declared.
E.g.: an int's value inside a function as a local variable would be stored on the stack, whilst an in int's value declared as member in a class would be stored on the heap with the class it is declared in. A value type on a class has a lifetype that is exactly the same as the class it is declared in, requiring almost no work by the garbage collector. It's more complicated though, i'd refer to #JonSkeet's book "C# In Depth" or his article "Memory in .NET" for a more concise explenation.
Advantages:
A value type does not need extra garbage collection. It gets garbage collected together with the instance it lives in. Local variables in methods get cleaned up upon method leave.
Drawbacks:
When large set of values are passed to a method the receiving variable actually copies so there are two redundant values in memory.
As classes are missed out.it losses all the oop benifits
Reference type:
Holds a memory address of a value not value
Example:
Class
Storage:
Stored on heap
Advantages:
When you pass a reference variable to a method and it changes it indeed changes the original value whereas in value types a copy of the given variable is taken and that's value is changed.
When the size of variable is bigger reference type is good
As classes come as a reference type variables, they give reusability, thus benefitting Object-oriented programming
Drawbacks:
More work referencing when allocating and dereferences when reading the value.extra overload for garbage collector

I found it easier to understand the difference of the two if you know how computer allocate stuffs in memory and know what a pointer is.
Reference is usually associated with a pointer. Meaning the memory address where your variable reside is actually holding another memory address of the actual object in a different memory location.
The example I am about to give is grossly over simplified, so take it with a grain of salt.
Imagine computer memory is a bunch of PO boxes in a row (starting w/ PO Box 0001 to PO Box n) that can hold something inside it. If PO boxes doesn't do it for you, try a hashtable or dictionary or an array or something similar.
Thus, when you do something like:
var a = "Hello";
the computer will do the following:
allocate memory (say starting at memory location 1000 for 5 bytes) and put H (at 1000), e (at 1001), l (at 1002), l (at 1003) and o (at 1004).
allocate somewhere in memory (say at location 0500) and assigned it as the variable a.
So it's kind of like an alias (0500 is a).
assign the value at that memory location (0500) to 1000 (which is where the string Hello start in memory). Thus the variable a is holding a reference to the actual starting memory location of the "Hello" string.
Value type will hold the actual thing in its memory location.
Thus, when you do something like:
var a = 1;
the computer will do the following:
allocate a memory location say at 0500 and assign it to variable a (the same alias thing)
put the value 1 in it (at memory location 0500).
Notice that we are not allocating extra memory to hold the actual value (1).
Thus a is actually holding the actual value and that's why it's called value type.

This is from a post of mine from a different forum, about two years ago. While the language is vb.net (as opposed to C#), the Value Type vs. Reference type concepts are uniform throughout .net, and the examples still hold.
It is also important to remember that within .net, ALL types technically derive from the base type Object. The value types are designed to behave as such, but in the end they also inherit the functionality of base type Object.
A. Value Types are just that- they represent a distinct area in memory where a discrete VALUE is stored. Value types are of fixed memory size and are stored in the stack, which is a collection of addresses of fixed size.
When you make a statement like such:
Dim A as Integer
DIm B as Integer
A = 3
B = A
You have done the following:
Created 2 spaces in memory sufficient to hold 32 bit integer values.
Placed a value of 3 in the memory allocation assigned to A
Placed a value of 3 in the memory allocation assigned to B by assigning it the same value as the held in A.
The Value of each variable exists discretely in each memory location.
B. Reference Types can be of various sizes. Therefore, they can't be stored in the "Stack" (remember, the stack is a collection of memory allocations of fixed size?). They are stored in the "Managed Heap". Pointers (or "references") to each item on the managed heap are maintained in the stack (Like an Address). Your code uses these pointers in the stack to access objects stored in the managed heap. So when your code uses a reference variable, it is actually using a pointer (or "address" to an memory location in the managed heap).
Say you have created a Class named clsPerson, with a string Property Person.Name
In this case, when you make a statement such as this:
Dim p1 As clsPerson
p1 = New clsPerson
p1.Name = "Jim Morrison"
Dim p2 As Person
p2 = p1
In the case above, the p1.Name Property will Return "Jim Morrison", as you would expect. The p2.Name property will ALSO return "Jim Morrison", as you would Iintuitively expect. I believe that both p1 and p2 represent distinct addresses on the Stack. However, now that you have assigned p2 the value of p1, both p1 and p2 point to the SAME LOCATION on the managed heap.
Now COnsider THIS situation:
Dim p1 As clsPerson
Dim p2 As clsPerson
p1 = New clsPerson
p1.Name = "Jim Morrison"
p2 = p1
p2.Name = "Janis Joplin"
In this situation, You have created one new instance of the person Class on the Managed Heap with a pointer p1 on the Stack which references the object, and assigned the Name Property of the object instance a value of "Jim Morrison" again. Next, you created another pointer p2 in the Stack, and pointed it at the same address on the managed heap as that referenced by p1 (when you made the assignement p2 = p1).
Here comes the twist. When you the Assign the Name property of p2 the value "Janis Joplin" you are changing the Name property for the object REFERENCED by Both p1 and p2, such that, if you ran the following code:
MsgBox(P1.Name)
'Will return "Janis Joplin"
MsgBox(p2.Name)
'will ALSO return "Janis Joplin"Because both variables (Pointers on the Stack) reference the SAME OBJECT in memory (an Address on the Managed Heap).
Did that make sense?
Last. If you do THIS:
DIm p1 As New clsPerson
Dim p2 As New clsPerson
p1.Name = "Jim Morrison"
p2.Name = "Janis Joplin"
You now have two distinct Person Objects. However, the minute you do THIS again:
p2 = p1
You have now pointed both back to "Jim Morrison". (I am not exactly sure what happened to the Object on the Heap referenced by p2 . . . I THINK it has now gone out of scope. This is one of those areas where hopefullly someone can set me straight . . .). -EDIT: I BELIEVE this is why you would Set p2 = Nothing OR p2 = New clsPerson before making the new assignment.
Once again, if you now do THIS:
p2.Name = "Jimi Hendrix"
MsgBox(p1.Name)
MsgBox(p2.Name)
Both msgBoxes will now return "Jimi Hendrix"
This can be pretty confusing for a bit, and I will say one last time, I may have some of the details wrong.
Good Luck, and hopefully others who know better than me will come along to help clarify some of this . . .

value data type and reference data type
1) value( contain the data directly )
but
reference ( refers to the data )
2) in value( every variable has its own copy)
but
in reference (more than variable can refer to some objects)
3) in value (operation variable can`t effect on other variable )
but
in reference (variable can affect other )
4) value types are(int, bool, float)
but
reference type are (array , class objects , string )

Value Type:
Fixed memory size.
Stored in Stack memory.
Holds actual value.
Ex. int, char, bool, etc...
Reference Type:
Not fixed memory.
Stored in Heap memory.
Holds memory address of actual value.
Ex. string, array, class, etc...

"Variables that are based on value types directly contain values. Assigning one value type variable to another copies the contained value. This differs from the assignment of reference type variables, which copies a reference to the object but not the object itself." from Microsoft's library.
You can find a more complete answer here and here.

Sometimes explanations won't help especially for the beginners. You can imagine value type as data file and reference type as a shortcut to a file.
So if you copy a reference variable you only copy the link/pointer to a real data somewhere in memory. If you copy a value type, you really clone the data in memory.

This is probably wrong in esoterical ways, but, to make it simple:
Value types are values that are passed normally "by value" (so copying them). Reference types are passed "by reference" (so giving a pointer to the original value). There isn't any guarantee by the .NET ECMA standard of where these "things" are saved. You could build an implementation of .NET that is stackless, or one that is heapless (the second would be very complex, but you probably could, using fibers and many stacks)
Structs are value type (int, bool... are structs, or at least are simulated as...), classes are reference type.
Value types descend from System.ValueType. Reference type descend from System.Object.
Now.. In the end you have Value Type, "referenced objects" and references (in C++ they would be called pointers to objects. In .NET they are opaque. We don't know what they are. From our point of view they are "handles" to the object). These lasts are similar to Value Types (they are passed by copy). So an object is composed by the object (a reference type) and zero or more references to it (that are similar to value types). When there are zero references the GC will probably collect it.
In general (in the "default" implementation of .NET), Value type can go on the stack (if they are local fields) or on the heap (if they are fields of a class, if they are variables in an iterator function, if they are variables referenced by a closure, if they are variable in an async function (using the newer Async CTP)...). Referenced value can only go to the heap. References use the same rules as Value types.
In the cases of Value Type that go on the heap because they are in an iterator function, an async function, or are referenced by a closure, if you watch the compiled file you'll see that the compiler created a class to put these variables, and the class is built when you call the function.
Now, I don't know how to write long things, and I have better things to do in my life. If you want a "precise" "academic" "correct" version, read THIS:
http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx
It's 15 minutes I'm looking for it! It's better than the msdn versions, because it's a condensed "ready to use" article.

The simplest way to think of reference types is to consider them as being "object-IDs"; the only things one can do with an object ID are create one, copy one, inquire or manipulate the type of one, or compare two for equality. An attempt to do anything else with an object-ID will be regarded as shorthand for doing the indicated action with the object referred to by that id.
Suppose I have two variables X and Y of type Car--a reference type. Y happens to hold "object ID #19531". If I say "X=Y", that will cause X to hold "object ID #19531". Note that neither X nor Y holds a car. The car, otherwise known as "object ID #19531", is stored elsewhere. When I copied Y into X, all I did was copy the ID number. Now suppose I say X.Color=Colors.Blue. Such a statement will be regarded as an instruction to go find "object ID#19531" and paint it blue. Note that even though X and Y now refer to a blue car rather than a yellow one, the statement doesn't actually affect X or Y, because both still refer to "object ID #19531", which is still the same car as it always has been.

Variable types and Reference Value are easy to apply and well applied to the domain model, facilitate the development process.
To remove any myth around the amount of "value type", I will comment on how this is handled on the platform. NET, specifically in C # (CSharp) when called APIS and send parameters by value, by reference, in our methods, and functions and how to make the correct treatment of the passages of these values.
Read this article Variable Type Value and Reference in C #

Suppose v is a value-type expression/variable, and r is a reference-type expression/variable
x = v
update(v) //x will not change value. x stores the old value of v
x = r
update(r) //x now refers to the updated r. x only stored a link to r,
//and r can change but the link to it doesn't .
So, a value-type variable stores the actual value (5, or "h"). A reference-type varaible only stores a link to a metaphorical box where the value is.

Before explaining the different data types available in C#, it's important to mention that C# is a strongly-typed language. This means that each variable, constant, input parameter, return type and in general every expression that evaluates to a value, has a type.
Each type contains information that will be embedded by the compiler into the executable file as metadata which will be used by the common language runtime (CLR) to guarantee type safety when it allocates and reclaims memory.
If you wanna know how much memory a specific type allocates, you can use the sizeof operator as follows:
static void Main()
{
var size = sizeof(int);
Console.WriteLine($"int size:{size}");
size = sizeof(bool);
Console.WriteLine($"bool size:{size}");
size = sizeof(double);
Console.WriteLine($"double size:{size}");
size = sizeof(char);
Console.WriteLine($"char size:{size}");
}
The output will show the number of bytes allocated by each variable.
int size:4
bool size:1
double size:8
char size:2
The information related to each type are:
The required storage space.
The maximum and minimum values. For example, the type Int32 accepts values between 2147483648 and 2147483647.
The base type it inherits from.
The location where the memory for variables will be allocated at run time.
The kinds of operations that are permitted.
The members (methods, fields, events, etc.) contained by the type. For example, if we check the definition of type int, we will find the following struct and members:
namespace System
{
[ComVisible(true)]
public struct Int32 : IComparable, IFormattable, IConvertible, IComparable<Int32>, IEquatable<Int32>
{
public const Int32 MaxValue = 2147483647;
public const Int32 MinValue = -2147483648;
public static Int32 Parse(string s, NumberStyles style, IFormatProvider provider);
...
}
}
Memory management
When multiple processes are running on an operating system and the amount of RAM isn't enough to hold it all, the operating system maps parts of the hard disk with the RAM and starts storing data in the hard disk. The operating system will use than specific tables where virtual addresses are mapped to their correspondent physical addresses to perform the request. This capability to manage the memory is called virtual memory.
In each process, the virtual memory available is organized in the following 6 sections but for the relevance of this topic, we will focus only on the stack and the heap.
Stack
The stack is a LIFO (last in, first out) data structure, with a size-dependent on the operating system (by default, for ARM, x86 and x64 machines Windows's reserve 1MB, while Linux reserve from 2MB to 8MB depending on the version).
This section of memory is automatically managed by the CPU. Every time a function declares a new variable, the compiler allocates a new memory block as big as its size on the stack, and when the function is over, the memory block for the variable is deallocated.
Heap
This region of memory isn't managed automatically by the CPU and its size is bigger than the stack. When the new keyword is invoked, the compiler starts looking for the first free memory block that fits the size of the request. and when it finds it, it is marked as reserved by using the built-in C function malloc() and a return the pointer to that location. It's also possible to deallocate a block of memory by using the built-in C function free(). This mechanism causes memory fragmentation and has to use pointers to access the right block of memory, it's slower than the stack to perform the read/write operations.
Custom and Built-in types
While C# provides a standard set of built-in types representing integers, boolean, text characters, and so on, You can use constructs like struct, class, interface, and enum to create your own types.
An example of custom type using the struct construct is:
struct Point
{
public int X;
public int Y;
};
Value and reference types
We can categorize the C# type into the following categories:
Value types
Reference types
Value types
Value types derive from the System.ValueType class and variables of this type contain their values within their memory allocation in the stack. The two categories of value types are struct and enum.
The following example shows the member of the type boolean. As you can see there is no explicit reference to System.ValueType class, this happens because this class is inherited by the struct.
namespace System
{
[ComVisible(true)]
public struct Boolean : IComparable, IConvertible, IComparable<Boolean>, IEquatable<Boolean>
{
public static readonly string TrueString;
public static readonly string FalseString;
public static Boolean Parse(string value);
...
}
}
Reference types
On the other hand, the reference types do not contain the actual data stored in a variable, but the memory address of the heap where the value is stored. The categories of reference types are classes, delegates, arrays, and interfaces.
At run time, when a reference type variable is declared, it contains the value null until an object that has been created using the keywords new is assigned to it.
The following example shows the members of the generic type List.
namespace System.Collections.Generic
{
[DebuggerDisplay("Count = {Count}")]
[DebuggerTypeProxy(typeof(Generic.Mscorlib_CollectionDebugView<>))]
[DefaultMember("Item")]
public class List<T> : IList<T>, ICollection<T>, IEnumerable<T>, IEnumerable, IList, ICollection, IReadOnlyList<T>, IReadOnlyCollection<T>
{
...
public T this[int index] { get; set; }
public int Count { get; }
public int Capacity { get; set; }
public void Add(T item);
public void AddRange(IEnumerable<T> collection);
...
}
}
In case you wanna find out the memory address of a specific object, the class System.Runtime.InteropServices provides a way to access to managed objects from unmanaged memory. In the following example, we are gonna use the static method GCHandle.Alloc() to allocate a handle to a string and then the method AddrOfPinnedObject to retrieve its address.
string s1 = "Hello World";
GCHandle gch = GCHandle.Alloc(s1, GCHandleType.Pinned);
IntPtr pObj = gch.AddrOfPinnedObject();
Console.WriteLine($"Memory address:{pObj.ToString()}");
The output will be
Memory address:39723832
References
Official documentation: https://learn.microsoft.com/en-us/cpp/build/reference/stack-stack-allocations?view=vs-2019

I think these two pictures describe it the best. This is the case in languages like C#, Java, JavaScript, and Python. For C++ references mean different, and the equivalent of reference types are pointer types (That's why you see in various documents of different languages that they are used interchangeably). One of the important things is the meaning of "Pass by Value" and "Pass by Reference". I think there are other questions about them on StackOverflow you can seek for.

There are many little details of the differences between value types and reference types that are stated explicitly by the standard and some of them are not easy to understand, especially for beginners.
See ECMA standard 33, Common Language Infrastructure (CLI). The CLI is also standardized by the ISO. I would provide a reference but for ECMA we must download a PDF and that link depends on the version number. ISO standards cost money.
One difference is that value types can be boxed but reference types generally cannot be. There are exceptions but they are quite technical.
Value types cannot have parameter-less instance constructors or finalizers and they cannot refer to themselves. Referring to themselves means for example that if there is a value type Node then a member of Node cannot be a Node. I think there are other requirements/limitations in the specifications but if so then they are not gathered together in one place.

Why C# does not modify fields directly in the managed heap like C++/CLI?

As I see in the book C# via CLR writtern by Jeffrey Richter, when talking about boxing and unboxing/copying operations, Mr Richter shows a demo:
public static void Main() {
Point p; // Point is a value type defined before
p.x = p.y = 1;
Object o = p; // Boxes p; o refers to the boxed instance
// Change Point's x field to 2
p = (Point) o; // Unboxes o AND copies fields from boxed
// instance to stack variable
p.x = 2; // Changes the state of the stack variable
o = p; // Boxes p; o refers to a new boxed instance
}
In order to change the value of a boxed instance, we need to do an unboxing-then-boxing-again operation, the performance is not that good.
To avoid my misunderstanding of book, here is the exactly what the autor says:
However, in some languages like C++/CLI, they allow you to unbox a
boxed value type without copying the fields.Unboxing returns the
address of the unboxed portion of a boxed object (ignoring the
object’s type object pointer and sync block index overhead). You can
now use this pointer to manipulate the unboxed instance’s fields
(which happen to be in a boxed object on the heap). For example, the
previous code would be much more efficient if written in C++/CLI,
because you could change the value of Point’s x field within the
already boxed Point instance. This would avoid both allocating a new
object on the heap and copying all of the fields twice!
Here comes my question: Why C# does not do what C++/CLR does? Is there some other important issues prevent C# team to do this "redundant" design and make the performance not good as we expect? What's behind this "unnatural" behavior?

C# and C++ have somewhat different philosophies. Unlike C++, which is a system programming language, C# wants to save the programmer from dealing with memory allocation and pointers, so it tries to hide some of the details involved in memory management. In C#, value types are equivalent to primitive types and structs in C++. They are just a sequence of bytes somewhere in memory. In C++, you can easily declare a pointer to an int or struct, wherever it may reside, but C# won't allow that. This indirection is hidden inside the boxing/unboxing mechanism.
"Boxing" roughly means that the value type is created on the heap, and an object reference to this memory is silently returned. Unboxing simply reverses this indirection. Boxing/unboxing occurs automatically whenever you use a value type in a context where a reference type is expected - for instance, when casting an integer to an Object:
Int32 i4Value = 12345;
Object pValue = (Object) i4Value;
Casting an Object reference back to an integer automatically unboxes the value, i.e. copies it from the heap to a normal value.
The C++/CLI team did quite some wizardry to allow C++ programmers to use low-level C# features. This is one example. They exploit the C++ syntax to let you do some things a C# programmer isn't even aware of, because they happen somewhere behind the scenes.
Frankly, I've never been in need to use this special boxing/unboxing trick of C++/CLI, although I'm writing C++/CLI code all day long. However, there are certainly some situations where there's no other way - for instance, when interfacing some weird 3rd-party C# component that cannot be changed, because there's no source code available.

New Reference When Concatenating A String

A couple of weeks ago, I was asked a C# question in a job interview. The question was exactly this:
string a = "Hello, ";
for(int i = 0; i < 99999999; i++)
{
a += "world!";
}
I was asked exactly, "why this is a bad method for concatenated string?". My response was some sort of "readability, append should be chosen" etc.
But apparently, this is not the case according to the guy that was interviewing me. So, according to him, every time we concatenate a string, because of the structure of CLR, a new reference is created in memory. So, in the end of the following code, we would have 99999999 of string variable "a" in memory.
I thought, the objects are created just once in the stack as soon as a value is assigned to them (I'm not talking about heap). The way I knew was the memory allocation is done once in the stack for each primitive data types, their values are modified as needed and disposed when the execution of a scope is finished. Is that wrong? Or, are new references of variable "a" actually created in the stack every single time it is concatenated?
Can someone please explain how it works for stack? Many thanks.

First remember these two facts:
string is an immutable type (existing instances are never modified)
string is a reference type (the "value" of a string expression is a reference to the location where the instance is)
Therefore, a statement like:
a += "world!";
will work similar to a = a + "world!";. It will first follow the reference to the "old" a and concat that old string with the string "world!". This involves copying the contents of both old strings into a new memory location. That is the "+" part. It will then move the reference of a from pointing to the old location into pointing to the new location (the newly concatenated string). That is the "=" assignment part of the statement.
Now it follows that the old string instance is left with no references to it. So at some point, the garbage collector will remove it (and possibly move memory around to avoid "holes").
So I guess your job interviewer was absolutely right there. The loop of your question will create a bunch of (mostly very long!) strings in memory (in the heap since you want to be technical).
A simpler approach could be:
string a = "Hello, "
+ string.Concat(Enumerable.Repeat("world!", 999...));
Here we use string.Concat. That method will know it will need to concatenate a bunch of strings into one long string, and it can use some sort of expandable buffer (such as a StringBuilder or even a pointer type char*) internally to make sure it does not create a myriad of "dead" object instances in mememory.
(Do not use ToArray() or similar, as in string.Concat(Enumerable.Repeat("world!", 999...).ToArray()), of course!)

.NET distinguishes between ref and value types. string is a ref type. It is allocated on the heap without exception. It's lifetime is controlled by the GC.
So, in the end of the following code, we would have 99999999 of string variable "a" in memory.
99999999 have been allocated. Of course, some of them might be GC'ed already.
their values are modified as needed and disposed when the execution of a scope is finished
String is not a primitive or a value type. Those are allocated "inline" inside of something else such as the stack, an array or inside heap objects. They also can be boxed and become true heap objects. None of that applies here.
The problem with this code is not the allocation but the quadratic runtime complexity. I don't think this loop would ever finish in practice.

Reference types (i.e. classes & strings) are always created in the heap. Value types (such as structs) are created in the stack and are lost when a function ends execution.
However stating that after the loop you will have N objects in memory is not entirely true. In each evaluation of the of the
a += "world!";
statement you do create a new string. What happens to the previously created string is more complicated. The garbage collector now owns, since there is no other reference to it in your code and will release it at some point, which you don't exactly know when will happen.
Finally, the ultimate problem with this code is that you believe you are modifying an object, but strings are immutable, meaning you cannot really change their value once created. You can only create new ones and this is what the += operator is doing. This would be far more efficient with a StringBuilder which was made to be mutable.
EDIT
As requested, here's stack / heap related clarification. Value types are not always in the stack. They are in the stack when you declare them inside a function body:
void method()
{
int a = 1; // goes in the stack
}
But go into the heap when they are part of other objects, like when an integer is a property of a class (since the whole class instance is in the heap).

How do you store an int or other "C# value types" on the heap (with C#)?

I'm engaged in educating myself about C# via Troelsen's Pro C# book.
I'm familiar with the stack and heap and how C# stores these sorts of things. In C++, whenever we use new we receive a pointer to something on the heap. However, in C# the behavior of new seems different to me:
when used with value types like an int, using new seems to merely call the int default constructor yet the value of such an int would still be stored on the stack
I understand that all objects/structs and such are stored on the heap, regardless of whether or not new is used.
So my question is: how can I instantiate an int on the heap? (And does this have something to do with 'boxing'?)

You can box any value type to System.Object type so it will be stored on the managed heap:
int number = 1;
object locatedOnTheHeap = number;
An other question is why you need this.
This is a classic example from the must-know MSDN paper: Boxing and Unboxing (C# Programming Guide)
When the CLR boxes a value type, it wraps the value inside a
System.Object and stores it on the managed heap.
Boxing is used to store value types in the garbage-collected heap.
Boxing is an implicit conversion of a value type to the type object or
to any interface type implemented by this value type. Boxing a value
type allocates an object instance on the heap and copies the value
into the new object.
.
I understand that all objects/structs and such are stored on the heap
BTW, IIRC sometimes JIT optimizes code so value type objects like of type like int are stored in the CPU registers rather than stack.

I do not know why you would want to do this, however, in theory you could indeed box your value. You would do this by boxing the int into an object (which is a reference type and will be placed on the stack:
object IAmARefSoIWillBeOnHeap = (object)1;
*As sll stated, you do not need the (object) as it will be an implicit cast. This is here merely for academic reasons, to show what is happening.
Here is a good article about reference versus value types, which is the difference of the heap versus the stack

A value type is "allocated" wherever it is declared:
As a local variable, typically on the stack (but to paraphrase Eric Lippert, the stack is an implementation detail, I suggest you read his excellent piece on his blog: The Truth About Value Types.)
As a field in a class, it expands the size of the instance with the size of the value type, and takes up space inside the instance
As such, this code:
var x = new SomeValueType();
does not allocate something on the heap by itself for that value type. If you close over it with an anonymous method or similar, the local variable will be transformed into the field of a class, and an instance of that class will be allocated on the heap, but in this case, the value type will be embedded into that class as a field.
The heap is for instances of reference types.
However, you've touched up something regarding boxing. You can box a value type value to make a copy of it and place that copy on the heap, wrapped in an object.
So this:
object x = new SomeValueType();
would first allocate the value type, then box it into an object, and store the reference to that object in x.

yet the value of such an int would still be stored on the stack
This is not necessarily true. Even when it is true, it's purely an implementation detail, and not part of the specification of the language. The main issue is that the type system does not necessarily correlate to the storage mechanism used by the runtime.
There are many cases where calling new on a struct will still result in an object that isn't on the stack. Boxing is a good example - when you box an object, you're basically pushing it into an object (effectively "copying" it to the heap), and referencing the object. Also, any time you're closing over a value type with a lambda, you'll end up "allocating on the heap."
That being said, I wouldn't focus on this at all - the issue really shouldn't about stack vs. heap in allocations, but rather about value type vs. reference type semantics and usage. As such, I'd strongly recommend reading Eric Lippert's The Truth About Value Types and Jon Skeet's References and Values. Both of these articles focus on the important aspects of struct vs. class semantics instead of necessarily looking at the storage.
As for ways to force the storage of an int on the heap, here are a couple of simple ones:
object one = 1; // Boxing
int two = 2; // Gets closed over, so ends up "on the heap"
Action closeOverTwo = () => { Console.WriteLine(two); }
// Do stuff with two here...
var three = new { Three = 3 }; // Wrap in a value type...

If you want an int on the heap, you can do this:
object o = 4;
But basically, you shouldn't want that. C# is designed for you not to think about such things. Here's a good place to start on that: http://blogs.msdn.com/b/ericlippert/archive/2009/04/27/the-stack-is-an-implementation-detail.aspx

So my question is: how can I instantiate an int on the heap? (And does
this have something to do with 'boxing'?)
Your understanding about objects and structs are correct. When you intialized either an object or a structure it goes on the heap.

Why are C# number types immutable?

Why are ints and doubles immutable? What is the purpose of returning a new object each time you want to change the value?
The reason I ask is because I'm making a class: BoundedInt, which has a value and an upper and lower bound. So I was wondering: should I make this type immutable too? (Or should it be a struct?)

Firstly:
What is the purpose of returning a new object each time you want to change the value?
I think you might be mistaken about how value types work. This isn't some costly operation like you may be imagining; it's simply the overwriting of data (as opposed to, e.g., dynamic allocation of new memory).
Secondly: here's a very simple example of why numbers are immutable:
5.Increase(1);
Console.WriteLine(5); // What should happen here?
Granted, that is a contrived example. So let's consider a couple more involved ideas.
Mutable reference type
First, there's this one: what if Integer were a mutable reference type?
class Integer
{
public int Value;
}
Then we could have code like this:
class Something
{
public Integer Integer { get; set; }
}
And:
Integer x = new Integer { Value = 10 };
Something t1 = new Something();
t1.Integer = x;
Something t2 = new Something();
t2.Integer = t1.Integer;
t1.Integer.Value += 1;
Console.WriteLine(t2.Integer.Value); // Would output 11
This seems to defy intuition: that the line t2.Integer = t1.Integer would simply copy a value (actually, it does; but that "value" is in fact a reference) and thus that t2.Integer would remain independent of t1.Integer.
Mutable value type
This could be approached another way, of course, keeping Integer as a value type but maintaining its mutability:
struct Integer
{
public int Value;
// just for kicks
public static implicit operator Integer(int value)
{
return new Integer { Value = value };
}
}
But now let's say we do this:
Integer x = 10;
Something t = new Something();
t.Integer = x;
t.Integer.Value += 1; // This actually won't compile; but if it did,
// it would be modifying a copy of t.Integer, leaving
// the actual value at t.Integer unchanged.
Console.WriteLine(t.Integer.Value); // would still output 10
Basically, immutability of values is something that is highly intuitive. The opposite is highly unintuitive.
I guess that is subjective, though, in all fairness ;)

Integer variables are mutable. However, integer literals are constants, hence immutable.
int i = 0;
// Mutation coming!
i += 3;
// The following line will not compile.
3 += 7;
It's possible to make an integer field immutable, using readonly. Likewise, an integer property could be get-only.

As a mutable object, you have to lock an int variable before you change it (in any multi-threaded code that writes to your int from separate threads).
Why? Let's say you were incrementing an int, like this:
myInt++
Under the hood, this is a 32-bit number. Theoretically, on a 32 bit computer you could add 1 to it, and this operation might be atomic; that is, it would be accomplished in one step, because it would be accomplished in a CPU register. Unfortunately, it's not; there is more going on than this.
What if another thread mutated this number while it was in the middle of being incremented? Your number would get corrupted.
However, if you make a thread-safe copy of your object before you increment it, operate on your thread-safe copy, and return a new object when your increment is complete, you guarantee that your increment is thread safe; it cannot be affected by any operations on the original object that take place on other threads, because you're no longer working with the original object. In effect, you have made your object immutable.
This is the basic principle behind functional programming; by making objects immutable, and returning new objects from functions, you get thread safety for free.

It makes sense to have BoundedInt as a mutable type because it represents a variable that at any point in time has a specific value and that value can be changed but only within a certain range.
However integers themselves aren't variables so they should not be mutable.

Anything with value semantics should be immutable in C#.
Mutable classes can't have value semantics because you can't override the assignment operator.
MyClass o1=new MyClass();
MyClass o2=o1;
o1.Mutate();
//o2 got mutated too
//=> no value but reference semantics
Mutable structs are ugly because you can easily call a mutating method on a temporary variable. In particular properties return temporary variables.
MyStruct S1;
MyStruct S2{get;set;}
S1.Mutate(); //Changes S1
S2.Mutate();//Doesn't change S2
That's why I don't like that most Vector libraries use mutating methods like Normalize in their Vector struct.

I'm working on an academic project with Neural Networks. These networks do heavy computation with doubles. I run it on amazon cloud for days on 32 core servers. When profiling the application, the top performance problem is allocation of double!!
It would be fair to have a dedicated namespace with mutable types. "unsafe" keywords can be enforced for additional precaution.

Develop Reference

C# (C-Sharp) is a programming language developed by Microsoft that runs on the .NET Framework.