ansaurus

Question

c# - is SHORT data type or it is still INT?

Answer 1

+4 A:

In C#, the following things are always true:

short == Int16
ushort == UInt16
int == Int32
uint == UInt32
long == Int64
ulong == UInt64

Both versions are data types. All of the above are integers of various lengths and signed-ness.

The main difference between the two versions (as far as I know) is what colour they are highlighted as in Visual Studio.

Mike Caron 2010-08-07 16:38:37

The color is probably related to whether they are keywords. So you could probably name a variable `Int32`, but not `int`.

Philipp 2010-08-07 16:45:12

The difference is that the left column contains native C# names, which are preferable. The exception is that calls to static methods and properties of these classes, which should be to the CLR names.

Steven Sudit 2010-08-07 16:46:15

@Philipp Ah, this is true. I didn't think about that. Not that you should ever name a variable Int32! ;)

Mike Caron 2010-08-07 16:46:22

@Philipp: Perhaps you could, but I wouldn't!

Steven Sudit 2010-08-07 16:46:37

@Steven don't forget, `typeof(int)` is Int32, and it will show up as such in stack traces, etc. So it's still good know.

Mike Caron 2010-08-07 16:47:18

@Mike: Totally agreed.

Steven Sudit 2010-08-07 17:16:49

all the types in the left columns are just aliases for the types in the right column! The only difference between the usage of these types is syntactical. The types on the left are there to make the programmers lives easier.

Henri 2010-08-07 17:24:48

@Philipp: You can still use `int` as a name, you just need to prefix it with @ - for example: `int @int = 0;`. The name is still `int`. I wouldn't recommend this though :)

Jon Skeet 2010-08-07 17:28:41

Answer 2

+2 A:

short is a data type representing 16-bit integers (1 order below int, which is 32-bit).

Int16 is in fact also a data type and is synonymous with short. That is,

Int16.Parse(someNumber);

also returns a short, same as:

short.Parse(someNumber)

Same goes with Int32 for int and Int64 for long.

BoltClock 2010-08-07 16:39:03

Answer 3

+2 A:

In C#, int is just a shorter way of saying System.Int32.

In .NET, even the primitive data types are actually objects (derived from System.Object).

So an int in C# = an Integer in VB.Net = System.Int32.

there's a chart of all the .NET data types here: http://msdn.microsoft.com/en-us/library/47zceaw7%28VS.71%29.aspx

This is part of the .NET Common Type System that allows seamless interoperability between .NET languages.

David Stratton 2010-08-07 16:39:17

"In .NET, even the primitive data types are actually object" are you sure about this? I always thought of primitives as not derived from object, and converting from and to object requires boxing and unboxing (which the c# compiler hides from you, but still happens at IL level. The old managed c++ (before c++/CLI) made it explicit using __box and __unbox or something similar)

Ben Schwehn 2010-08-07 17:14:17

@Ben: That's Java. In .NET, value types may be *stored* unboxed, but they still logically derive from `System.Object`, so they can always be used where an `Object` is required. And, yes, this does mean they get automatically boxed, with the boxed version being explicitly derived from `Object`.

Steven Sudit 2010-08-07 17:18:21

I think you are both right. Behind the scenes, int is generally a 4-byte piece of memory, but logically it's a struct derived from object, and the necessary automatic boxing happens to maintain that appearance. So really, whether or not it's an object depends on the conceptual level you are talking about.

Jon Hanna 2010-08-07 17:27:14

So I checked Richter's CLR via C# and I think what's happening is: all value types derive from System.ValueType and System.ValueType itself derives from System.Object. So saying that all primitives are objects is indeed correct! ValueTypes are allocated on the stack. Boxing allocates the necessary memory on the heap plus two additional fields (type object pointer and sync block index) required by objects on the heap and then copies the ValueType into the newly allocated heap memory. Boxing does not happen automatically, but the c# compiler inserts the IL code required for boxing automatically

Ben Schwehn 2010-08-07 17:37:16

...so it's all objects, but objects on the stack behave different than objects on the heap. So the difference is not in "things that derive from object" versus "things that do not derive from object" but "stack" versus "heap". IIRC c++/CLI allows putting arbitrary objects (i.e. not objects not derived from ValueType) on the stack.

Ben Schwehn 2010-08-07 17:40:22

Wow... This is a lot of discussion on a point that's covered in almost every intro to .Net book and article I've ever read, not to mention, it's covered in the official documentation, which I linked to initially. (Click on the link to the Common Type system in my answer, and then follow the first link. It points here: http://msdn.microsoft.com/en-us/library/2hf02550%28VS.71%29.aspx where it clearly describes everything you're talking about and backs up my short answer.

David Stratton 2010-08-07 17:48:41

Answer 4

A:

What hasn't been mentioned in any of the other answers is the value type System.IntPtr, whose bit width is platform-specific; e.g. on a 32-bit system, it is 32 bits wide, while on a 64-bit system, it is 64 bits wide.

That being said, from all I can gather this type is not meant to actually be used in place of any of the other int types; its main use probably lies with P/Invoke-ing to the underlying system API, where it's normally used for holding pointers.

stakx 2010-08-07 17:06:38

ansaurus

tags:

views:

answers:

c# - is SHORT data type or it is still INT?

related questions