Hmmm...int32 or integer for 64bit windows?

[Stuart Anderson]

Hi folks,

I'm curious about the following. Obv in VB.NET there are both Int32 and
Integer datatypes, both being 32bit. My question is what happens if you
compile on 64bit windows? obviously (I assume!) the 32bit int stays at
32bit but does the Integer compile to 64bits? I would assume not but I'm
sure I read something about it being designed so that by compiling on 64bit
Windows the Integer would be 64bit for max performance.

Problem is I can't remember where I read it, *if* I read it *-) and if so
what the **** happens! It's not really a major issue for me at the moment
but the software we are writing should have a long and healthy lifespan
(Possibly longer than a week!) and we would obviously prefer maximum
performance on 64bit windows as and when it's available.

Anyone out there with any light to shed? I've searched the book I thought I
read it in, and MSDN etc. Or am I just having a witching hour meltdown!

Thanks in advance,


Stuart Anderson.

[Bob Butler]

"Stuart Anderson" <s.anderson@corolus.com> wrote in message
news:3be9c929@147.208.176.211...
> Hi folks,
>
> I'm curious about the following. Obv in VB.NET there are both Int32 and
> Integer datatypes, both being 32bit. My question is what happens if you
> compile on 64bit windows? obviously (I assume!) the 32bit int stays at
> 32bit but does the Integer compile to 64bits? I would assume not but I'm
> sure I read something about it being designed so that by compiling on
64bit
> Windows the Integer would be 64bit for max performance.

'Integer' in VB.Net is defined as 32-bits and is simply an alias for
System.Int32 so they aren't two distinct data types, just two names for the
same thing. As far as I know from the definitions it will remain 32-bits
regardless of the underlying architecture. Of course, since "Integer" has
already been re-defined between versions there's no way to predict what will
happen in future versions.

[Cali LaFollett]

> I'm curious about the following. Obv in VB.NET there are both Int32 and
> Integer datatypes, both being 32bit. My question is what happens if you
> compile on 64bit windows? obviously (I assume!) the 32bit int stays at
> 32bit but does the Integer compile to 64bits? I would assume not but I'm
> sure I read something about it being designed so that by compiling on
64bit
> Windows the Integer would be 64bit for max performance.

I *think* (****, that's a bad thing to do! :-) Integer is meant to stay 32
bits. Personally I wish MS would treat "Integer" like Borland does and make
it float with the compiler. Delphi has dedicated Integer types for when you
want 32 bits or 64 bits and plain ol' "Integer" is speced out to be what
ever the current compiler supports, which is currently 32 bits, so that
there is plenty of room for growth.

Keep in mind that Anders Hejlsberg was the designer of Delphi and is now
pretty much known as the father of .NET/C#. With this in mind, it may be a
safe bet to assume that the value of Integer may change in the future.

I know this wasn't a whole lot of info but hope it helps.

Cal

[Rob Teixeira]

Actually, Integer (Int32) is now tied to the submitted standards, and I don't
see it changing as long as it's in the context of .NET.
COM Automation Integer never changed in the context of COM.
Now, this is not to say that a version of the runtime meant for 64-bit OS's
doesn't optimize things, like widening or padding a variable before an operation
perhaps. But I believe that conceptually, Integer will likely remain 32-bits
in the .NET context.

However, a platform-dependant numeric type (which is meant for things like
pointers and handles that do change with processors) does exist and is called
IntPtr. IntPtr will be 32-bits on an 32-bit OS and 64-bits on a 64-bit OS.
No more changing code for API's when you move from one OS to the next (at
least in respect to pointers and handles).

Hope that answers Cal's question too.

-Rob

"Bob Butler" <butlerbob@earthlink.net> wrote:
>
>"Stuart Anderson" <s.anderson@corolus.com> wrote in message
>news:3be9c929@147.208.176.211...
>> Hi folks,
>>
>> I'm curious about the following. Obv in VB.NET there are both Int32 and
>> Integer datatypes, both being 32bit. My question is what happens if you
>> compile on 64bit windows? obviously (I assume!) the 32bit int stays at
>> 32bit but does the Integer compile to 64bits? I would assume not but
I'm
>> sure I read something about it being designed so that by compiling on
>64bit
>> Windows the Integer would be 64bit for max performance.
>
>'Integer' in VB.Net is defined as 32-bits and is simply an alias for
>System.Int32 so they aren't two distinct data types, just two names for
the
>same thing. As far as I know from the definitions it will remain 32-bits
>regardless of the underlying architecture. Of course, since "Integer" has
>already been re-defined between versions there's no way to predict what
will
>happen in future versions.
>
>
>
>

[Bob Butler]

"Rob Teixeira" <RobTeixeira@@msn.com> wrote in message
news:3be9ec06$1@147.208.176.211...
>
>
> Actually, Integer (Int32) is now tied to the submitted standards, and I
don't
> see it changing as long as it's in the context of .NET.

System.Int32 may be tied to submitted standards but I'm not aware of any
standards for VB.Net which means that MS can re-define the meaning of the
keyword whenever they decide to.

> COM Automation Integer never changed in the context of COM.
> Now, this is not to say that a version of the runtime meant for 64-bit
OS's
> doesn't optimize things, like widening or padding a variable before an
operation
> perhaps. But I believe that conceptually, Integer will likely remain
32-bits
> in the .NET context.

That would be my assumption as well. On the other hand, that's what I
thought about it being 16 bits also.

> However, a platform-dependant numeric type (which is meant for things like
> pointers and handles that do change with processors) does exist and is
called
> IntPtr. IntPtr will be 32-bits on an 32-bit OS and 64-bits on a 64-bit OS.
> No more changing code for API's when you move from one OS to the next (at
> least in respect to pointers and handles).

True, and having a defined way to access the platform-dependent size is
great.