boxing and unboxing in int and string

Question

I am little bit confused in boxing and unboxing. According to its definition

Boxing is implicit conversion of ValueTypes to Reference Types (Object).
UnBoxing is explicit conversion of Reference Types (Object) to its equivalent ValueTypes.

the best example for describing this is

int i = 123; object o = i;  // boxing

and

o = 123; i = (int)o;  // unboxing 

But my question is that whether int is value type and string is reference type so

int i = 123; string s = i.ToString();

and

s = "123"; i = (int)s; 

Is this an example of boxing and unboxing or not???

Erv

s = "123"; i = (int)s; won't compile – Forgiveness

why the OOP tag? Indeed C# is an OO language, but the issue asked does not seem to be related to the Object Oriented programming paradigm – Hamburg

@davka: Well, ToString is a virtual method on object which is then overridden by the Int32 type, so there's your (admittedly tenuous) OOP connection. – Snappish

@Hamburg I've now modified the OPs tags – Sting

Complex concepts, that happens because the programming language is messy, that why Functional programming is better. I like C#, but I always learn something new. – Freckly

Answer 1

Calling ToString is not boxing. It creates a new string that just happens to contain the textual representation of your int.

When calling (object)1 this creates a new instance on the heap that contains an int. But it's still an int. (You can verify that with o.GetType())

String can't be converted with a cast to int. So your code will not compile.

If you first cast your string to object your code will compile but fail at runtime, since your object is no boxed int. You can only unbox an value type into the exactly correct type(or the associated nullable).

Two examples:

Broken:

object o=i.ToString();// o is a string
int i2=(int)o;//Exception, since o is no int

Working:

object o=i;// o is a boxed int
int i2=(int)o;//works 

Family

Answer 2

 int i = 2;
 string s = i.ToString();

This is NOT boxing. This is simply a method call to Int32.ToString() which returns a formatted string representing the value of the int.

 i = (int)s;

This code will not compile as there is no explicit conversion defined between System.String and System.Int32.

Think of it in the following way to understand what is and what is not boxing and unboxing:

1. Boxing: Its when you take a value type and just "stick" it in a reference variable. There is no need of any type specific conversion logic for this operation to work. The variable type will still be the same if you use GetType().

2. Unboxing: Its just the opposite operation. Take a value type stuck in a reference object and assign it to a value type variable. Again there is no need for any type specific conversion logic for this operation to work.

   So if (int)s were valid, it would simply be a explicit conversion and not a unboxing operation, becuase s.GetType() would return System.String, not System.Int32.

Aegaeon

The boxed type for a nullable type will be the underlying type. And GetType always boxes, so the result of GetType on a normal nullable is the underlying type whereas typeof gives you the nullable type. – Family

Answer 3

Boxing/Unboxing: Conversion of Value Types to its object representation and vice versa (e.g. int and object).

The ToString() method in contrast is an operation which generated a new string, is has nothing to do with boxing/cast/type conversation.

Guinna

Answer 4

Late to the party on this, but...... I don't like simply reading answers and without proofs behind them. I like to understand the problem and analyse the possible solution and see if it ties in with my understanding. This copy and paste text from the rightly acclaimed excellent 'CLR via C#' by the god Jeff Richter explains this:

Even though unboxed value types don’t have a type object pointer, you can still call virtual methods (such as Equals, GetHashCode, or ToString) inherited or overridden by the type. If your value type overrides one of these virtual methods, then the CLR can invoke the method nonvirtually because value types are implicitly sealed and cannot have any types derived from them. In addition, the value type instance being used to invoke the virtual method is not boxed. However, if your override of the virtual method calls into the base type's implementation of the method, then the value type instance does get boxed when calling the base type's implementation so that a reference to a heap object get passed to the this pointer into the base method. However, calling a nonvirtual inherited method (such as GetType or MemberwiseClone) always requires the value type to be boxed because these methods are defined by System.Object, so the methods expect the this argument to be a pointer that refers to an object on the heap.

Mr Richter should be given a medal for this book. If you haven't got it, get it!! Then you'll get it :)

Etra

I don't know that the words "such as" in your second paragraph are needed, since those are the only three virtual methods that value types can support. The simplest way to explain the requirement for boxing when they are not overridden is to realize that each method takes an implied this parameter. If myStruct does not override ToString, the this parameter will be of type Object; if it does override it, the this parameter will be of type ref myStruct. Passing a myStruct variable an an Object` parameter requires boxing; passing it as a ref MyStruct parameter does not. – Lugansk