Converting to int16, int32, int64 - how do you know which one to choose?

Question

I often have to convert a retreived value (usually as a string) - and then convert it to an int. But in C# (.Net) you have to choose either int16, int32 or int64 - how do you know which one to choose when you don't know how big your retrieved number will be?

Answer 1

If we're just talking about a couple numbers, choosing the largest won't make a noticeable difference in your overall ram usage and will just work. If you are talking about lots of numbers, you'll need to use TryParse() on them and figure out the smallest int type, to save ram.

Answer 2

All computers are finite. You need to define an upper limit based on what you think your users requirements will be.

If you really have no upper limit and want to allow 'unlimited' values, try adding the .Net Java runtime libraries to your project, which will allow you to use the java.math.BigInteger class - which does math on nearly-unlimited size integer.

Note: The .Net Java libraries come with full DevStudio, but I don't think they come with Express.

Answer 3

Just wanted to add that... I remembered that in the days of .NET 1.1 the compiler was optimized so that 'int' operations are actually faster than byte or short operations.

I believe it still holds today, but I'm running some tests now.

---

EDIT: I have got a surprise discovery: the add, subtract and multiply operations for short(s) actually return int!

Answer 4

Everyone here who has mentioned that declaring an Int16 saves ram should get a downvote.

The answer to your question is to use the keyword "int" (or if you feel like it, use "Int32").

That gives you a range of up to 2.4 billion numbers... Also, 32bit processors will handle those ints better... also (and THE MOST IMPORTANT REASON) is that if you plan on using that int for almost any reason... it will likely need to be an "int" (Int32).

In the .Net framework, 99.999% of numeric fields (that are whole numbers) are "ints" (Int32).

Example: Array.Length, Process.ID, Windows.Width, Button.Height, etc, etc, etc 1 million times.

EDIT: I realize that my grumpiness is going to get me down-voted... but this is the right answer.

Answer 5

Repeatedly trying TryParse() doesn't make sense, you have a field already declared. You can't change your mind unless you make that field of type Object. Not a good idea.

Whatever data the field represents has a physical meaning. It's an age, a size, a count, etc. Physical quantities have realistic restraints on their range. Pick the int type that can store that range. Don't try to fix an overflow, it would be a bug.

Answer 6

Contrary to the current most popular answer, shorter integers (like Int16 and SByte) do often times take up less space in memory than larger integers (like Int32 and Int64). You can easily verify this by instantiating large arrays of sbyte/short/int/long and using perfmon to measure managed heap sizes. It is true that many CLR flavors will widen these integers for CPU-specific optimizations when doing arithmetic on them and such, but when stored as part of an object, they take up only as much memory as is necessary.

So, you definitely should take size into consideration especially if you'll be working with large list of integers (or with large list of objects containing integer fields). You should also consider things like CLS-compliance (which disallows any unsigned integers in public members).

For simple cases like converting a string to an integer, I agree an Int32 (C# int) usually makes the most sense and is likely what other programmers will expect.