tags:

views:

1711

answers:

6
+13  Q: 

sizeof(int) on x64?

When I do sizeof(int) in my C#.NET project I get a return value of 4. I set the project type to x64, so why does it say 4 instead of 8? Is this because I'm running managed code?

+26  A: 

The keyword int aliases System.Int32 which still requires 4 bytes, even on a 64-bit machine.

Andrew Hare
+16  A: 

int means Int32 in .NET languages. This was done for compatibility between 32- and 64-bit architectures.

Here's the table of all the types in C# and what they map to .NET wise.

Ben S
+2  A: 

Remember int is just a compiler alias for the basic type Int32. Given that it should be obvious why int is only 32 bits on a 64 bit platform.

Brian Rasmussen
+5  A: 

You may be thinking of an int pointer or System.IntPtr. This would be 8 bytes on an x64 and 4 bytes on an x86. The size of a pointer shows that you have 64-bit addresses for your memory. (System.IntPtr.Size == 8 on x64)

The meaning of int is still 4 bytes whether you are on an x86 or an x64. That is to say that an int will always correspond to System.Int32.

Brian R. Bondy
+4  A: 

An Int32 is 4 bytes on x86 and x64. An Int64 is 8 bytes either case. The C# int type is just an alias for Int32. Same under both runtime environments. The only type that does change depending on the runtime environment is an IntPrt:

    unsafe
    {
        var size = sizeof(IntPtr); // 4 on x86 bit machines. 8 on x64
    }
Andrew Robinson
Or you could just check IntPtr.Size, which does not require unsafe code.
Jim Mischel
... and UIntPtr, of course. ...and unsafe pointer types.
P Daddy
Good thing to note: UIntPtr is not CLS-Compliant.
Andrew Hare
+6  A: 

There are various 64-bit data models; Microsoft uses LP64 for .NET: both longs and pointers are 64-bits (although traditional C-style pointers don't exist .NET). Contrast this with ILP64 where ints are also 64-bits.

Thus, on all platforms, int is 32-bits and long is 64-bits; you can see this in the names of the underlying types System.Int32 and System.Int64.

Dan
You should edit your answer as it is the accepted one to make it completely correct. Remove where you say "although traditional C-style pointers don't exist .NET" and detail System.IntPtr depends on the architecture.
fnieto