|
You are right, what my code example shows is not boxing. It demonstrates that you can cast a reference stored in an object reference variable to the actual type or one of it's base types.
For boxing, you can only unbox to the actual type that was boxed. A value type can not inherit another value type, so there is never any base type that you could unbox to instead.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
|
George_George wrote: "A value type can not inherit another value type" -- so Object is just the base for all reference type, not value type?
No, all types are derived from Object.
George_George wrote: I do not agree with it, since all value types inherit from System.ValueType, and System.ValueType inherits from Object. Any comments?
A value type can not inherit another value type. It inherits the abstact class ValueType, but never any actual value type.
The documentation says:
"All value types are derived implicitly from the System.ValueType."
But also:
"Structs can implement an interface but they cannot inherit from another struct."
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
One further question, I think for primitive types, there are pairs of relationship, example int and Int32 are the same thing, only different in names. Is my understanding correct (I can not find answers from any books or search)?
regards,
George
|
|
|
|
|
Yes, in almost every aspect int and System.Int32 is exactly the same thing.
There are some special cases where there is a difference. You can for example not use System.Int32 to specify a type for an enum:
enum MyEnum : int { asdf }<br />
<br />
enum MyEnum : System.Int32 { asdf }
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
Good to learn from you. I have never used type information after Enum to restrict the type of Enum -- and just use the default one -- I think it is int type?
2.
So, a further question, what types could be used with Enum definition to define the type of the Enum?
regards,
George
|
|
|
|
|
George_George wrote: Good to learn from you. I have never used type information after Enum to restrict the type of Enum -- and just use the default one -- I think it is int type?
Yes, it's int.
George_George wrote: what types could be used with Enum definition to define the type of the Enum?
It can be any integral type except char (i.e. sbyte, byte, short, ushort, int, uint, long or ulong).
enum (C# reference)[^]
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Great link, Guffa!
One further question, I read the link and find there is a comment like this -- "Notice that if you remove the initializer from Sat=1, the result will be ...", my confusion is in the related sample, are there any Enum element named Sat?
regards,
George
|
|
|
|
|
George_George wrote: I read the link and find there is a comment like this -- "Notice that if you remove the initializer from Sat=1, the result will be ...", my confusion is in the related sample, are there any Enum element named Sat?
It's referring to the first example:
enum Days {Sat=1, Sun, Mon, Tue, Wed, Thu, Fri};
If you remove =1 from the Sat element, it will get the default value 0 instead of 1.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Correct, thanks Guffa!
regards,
George
|
|
|
|
|
Because everything is a pointer in .Net. Despite being an int, i could very well point to an "object", and the compiler really doesn't have any way of knowing that you're being stupid.
What you should have done was:
int i = 100;
object b = (object)i;
long l = (long)b;
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
|
John Simmons / outlaw programmer wrote: What you should have done was:
int i = 100;
object b = (object)i;
long l = (long)b;
No, that's not what he should have done. That doesn't differ anything at all from the original code. All you have done is to replace the implicit cast to object with an explicit cast, which produces exactly the same code as before.
This is what he should have done:
int i = 100;
object b = i;
long l = (int)b;
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Nope - it'll still fail. See my next reply to him in this thread.
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: Nope - it'll still fail.
Now you don't make sense. Try the code that I posted, and you'll see that it works.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
I did, and it aborts in the debugger.
The only way it would work is to cast using Convert.ToIn32 (which is a lot safer anyway).
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass..." - Dale Earnhardt, 1997
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
John Simmons / outlaw programmer wrote: I did, and it aborts in the debugger.
That sounds strange...
Aborts? What is that exactly? An exception?
I tried the code both in VS 2005 (C# 2.0) and VS 2008 (C# 3.0), and I can't get it to fail.
John Simmons / outlaw programmer wrote: The only way it would work is to cast using Convert.ToIn32
That doesn't make sense. Why would it not be possible to unbox an int?
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
1.
I have tried that it works because b will be unboxed to a temporary int, then int will be converted to long -- which are all legal, right?
2.
When we unbox a value type, we could only unbox to the exact original type, any other types allowed?
regards,
George
|
|
|
|
|
George_George wrote: I have tried that it works because b will be unboxed to a temporary int, then int will be converted to long -- which are all legal, right?
Yes. You can use implicit conversion from int to long:
long l = (int)b;
Or you can use explicit conversion from int to long:
long l = (long)(int)b;
George_George wrote: When we unbox a value type, we could only unbox to the exact original type, any other types allowed?
You can unbox to the actual type, or any (non-abstract) base type.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Sorry for my limited knowledge, Guffa!
I have tried to write some code to test your idea "You can unbox to the actual type, or any (non-abstract) base type.", I tried to write a struct, and write another struct to derives from it. It seems in C# it is not supported to have a struct inherits from another struct?
regards,
George
|
|
|
|
|
It's perfectly valid to cast an object to long.
Sure, in trivial cases like this, the compiler could do data-flow analysis; see that b is a boxed int and report a failure when unboxing it to long.
But do you want to make a certain kind of data-flow analysis mandatory for C# compilers?
Either you need to make the C# specifications extremely complex, or you need to make a C# compiler that violates the specification (since it would reject your program that is specified to fail at runtime, not at compile time).
|
|
|
|
|
Thanks Daniel,
It is ok for me the compiler does not check the data flow. My question is, I want to know what C# compiler check for type conversion (even if it is simple and can not find all the issues until runtime, I want to know the rules). Any ideas?
regards,
George
|
|
|
|
|
Part of the confusion here is that "(Type)expression" can have many meanings:
- type conversion
- unboxing
- boxing
- cast
What it means depends on the type of "expression" (the source type) and the type in the parenthesis (the target type).
If there is a conversion operator that converts from source type to target type, then that is used.
So "(long)an_int_variable" works because there is an conversion operator that sign-extends a 32-bit int to a 64-bit long.
Otherwise, if the source type is System.Object (or an interface) and the target type, then unboxing is used. Unboxing "unpacks" the value from box object. The box object must have exactly the correct type for this to work, otherwise you get an InvalidCastException at runtime.
If the source type is a value type and the target type is System.Object (or an interface implemented by that value type), then boxing is used. This means that a new object is created and the value is copied into it.
Otherwise, it's a cast; which basically means that a pointer is re-interpreted to point to a different object type. In this case, no conversion and no object creation happens.
You get a compile time error only if the compiler can see, by looking at source type and target type ONLY, that the conversion/cast would ALWAYS fail.
|
|
|
|
|
Thanks Daniel,
Great reply! Two more comments,
1.
What is the differences between conversion and cast?
2.
When we unbox an object, it must be the same type of the original value type or could be different in some situations?
regards,
George
|
|
|
|
|
Here are some examples:
int -> long: compiles, can never fail at runtime
int -> object -> long: compiles (int->object is valid boxing instruction, object->long is valid unboxing instruction), but always fails at runtime because a box containing int cannot be unboxed to long
int -> object -> int -> long: compiles and works at runtime
int -> IComparable -> int: same as int -> object -> int
int -> string: fails with compile error, there's no conversion operator int->string (ToString is not a conversion operator), and there's no way this cast could succeed
int -> object -> string: compiles (int->object is valid boxing instruction, object->string is valid cast), but always fails at run time because a boxed int cannot be cast to string.
long -> int: compiles, but might fail at runtime when the long is too large and integer overflow checking is enabled
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
