[ACCEPTED]-boxing and unboxing in int and string-boxing
ToString is not boxing. It creates a new 12 string that just happens to contain the 11 textual representation of your int.
When 10 calling
(object)1 this creates a new instance on 9 the heap that contains an int. But it's 8 still an
int. (You can verify that with
String 7 can't be converted with a cast to
int. So your 6 code will not compile.
If you first cast 5 your string to
object your code will compile but 4 fail at runtime, since your object is no 3 boxed int. You can only unbox an value type 2 into the exactly correct type(or the associated 1 nullable).
object o=i.ToString();// o is a string int i2=(int)o;//Exception, since o is no int
object o=i;// o is a boxed int int i2=(int)o;//works
int i = 2; string s = i.ToString();
This is NOT boxing. This is simply a method 19 call to
Int32.ToString() which returns a formatted string 18 representing the value of the
i = (int)s;
This code 17 will not compile as there is no explicit 16 conversion defined between
Think of 15 it in the following way to understand what 14 is and what is not boxing and unboxing:
Boxing: Its when 13 you take a value type and just "stick" it 12 in a reference variable. There is no need 11 of any type specific conversion logic for 10 this operation to work. The variable type 9 will still be the same if you use
Unboxing: Its 8 just the opposite operation. Take a value 7 type stuck in a reference object and assign 6 it to a value type variable. Again there 5 is no need for any type specific conversion 4 logic for this operation to work.
(int)swere 3 valid, it would simply be a explicit conversion 2 and not a unboxing operation, becuase
s.GetType()would return 1
Boxing/Unboxing: Conversion of Value Types 5 to its object representation and vice versa 4 (e.g. int and object).
The ToString() method 3 in contrast is an operation which generated 2 a new string, is has nothing to do with 1 boxing/cast/type conversation.
Late to the party on this, but...... I don't 33 like simply reading answers and without 32 proofs behind them. I like to understand 31 the problem and analyse the possible solution 30 and see if it ties in with my understanding. This 29 copy and paste text from the rightly acclaimed 28 excellent 'CLR via C#' by the god Jeff Richter 27 explains this:
Even though unboxed value 26 types don’t have a type object pointer, you 25 can still call virtual methods (such as 24 Equals, GetHashCode, or ToString) inherited 23 or overridden by the type. If your value 22 type overrides one of these virtual methods, then 21 the CLR can invoke the method nonvirtually 20 because value types are implicitly sealed 19 and cannot have any types derived from them. In 18 addition, the value type instance being 17 used to invoke the virtual method is not 16 boxed. However, if your override of the 15 virtual method calls into the base type's 14 implementation of the method, then the value 13 type instance does get boxed when calling 12 the base type's implementation so that a 11 reference to a heap object get passed to 10 the this pointer into the base method. However, calling 9 a nonvirtual inherited method (such as GetType 8 or MemberwiseClone) always requires the 7 value type to be boxed because these methods 6 are defined by System.Object, so the methods 5 expect the this argument to be a pointer 4 that refers to an object on the heap.
Mr 3 Richter should be given a medal for this 2 book. If you haven't got it, get it!! Then 1 you'll get it :)
More Related questions