Double not a class but struct

  • Thread starter Thread starter rk
  • Start date Start date
R

rk

Folks,

Any comment on why these types (Double, Int16 etc.) are struct but not
a class. I was trying to pass an object type to a method that takes
Double hoping that it will work but just realized that the Double is
not derived from Object.

thanks
--rk
 
Hoping? ... wow.

Read up on the difference between value types (structs, enums) vs. reference
types (classes, delegates, etc) in the .NET SDK.
 
Hi
1) To my knowledge everything is derived from System.object in .NET so
also all .NET datatypes. Int , int16 etc etc all derive from a class of
type System.object. And structures give a way to define your user
defined value types.

2) But below the System.object .NET framework decides whether its
should be allocated on stack (Value types) or heap (Reference types).

3) In your case double is Value type and Object is reference type. They
can cast them , which is termed as Boxing and Unboxing concepts.

4) I think you can do if you use (double) objectname.



Shivprasad Koirala
C# , VB.NET , SQL SERVER , ASP.NET Interview Questions
http://www.geocities.com/dotnetinterviews/
 
1) To my knowledge everything is derived from System.object in .NET so
also all .NET datatypes. Int , int16 etc etc all derive from a class of
type System.object. And structures give a way to define your user
defined value types.

No, value types themselves don't derive from anything. Their *boxed*
versions derive from System.Object (via System.ValueType) but the
unboxed version doesn't.
2) But below the System.object .NET framework decides whether its
should be allocated on stack (Value types) or heap (Reference types).

Value types can live on the heap too, as part of other objects. Please
see
http://www.pobox.com/~skeet/csharp/memory.html
3) In your case double is Value type and Object is reference type. They
can cast them , which is termed as Boxing and Unboxing concepts.

Yes, this is boxing.
4) I think you can do if you use (double) objectname.

Well, that's going the other way (unboxing) but yes.
 
Jon Skeet said:
No, value types themselves don't derive from anything. Their *boxed*
versions derive from System.Object (via System.ValueType) but the
unboxed version doesn't.

Looking MSDN System.ValueType inherits directly from System.Object.

Regarding the original question Int32 and Double (such as all the value
types) are not class because it would be a disaster in situations as

int a = 10;
int b = a;
int a = 5; // b is 5???

or it would be impossible to manage something like

int a = 10;
int b = a + 1;
int a = 5; // be would be 11 or 6?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Back
Top