|
it _is_ possible to find that problem at compiletime. (in the context that the OP gave)
But that feature is not present in the current C# compiler(s)
And the reason it is not present is most likely that the benefit you would get from such feature is so small that it makes it pointless.
which I did state at the end of my post.
So what in that post makes it worth 1 votes?
modified on Sunday, May 4, 2008 2:02 PM
|
|
|
|
|
|
Thanks GuyThiebaut,
We can only unboxing to the original type? Could we unbox to a type's base type?
regards,
George
|
|
|
|
|
George_George wrote: Could we unbox to a type's base type?
Yes.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Thanks Guffa,
A little messy in the context. I want to confirm with you that you mean we can only unbox to the exact same original type (no other types are allowed)?
regards,
George
|
|
|
|
|
You can unbox to the actual type, or any (non-abstract) base type.
This works:
public class TypeX {}
public class TypeY : TypeX {}
TypeY y = new TypeY();
object o = y;
TypeX x = (TypeX)o;
Edit:
A more useful example of when you unbox to a base type, is when you box from a base type:
public class Animal {}
public class Dog : Animal {}
public class Horse : Animal {}
Animal hero = new Horse();
object o = hero;
Animal horsie = (Animal)o;
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Sorry, Guffa!
I am confused. In my understanding, boxing/unboxing only happens with value types, classes are not value types, but you are using classes in your sample? Any comments?
regards,
George
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
