Integer Do's And Don'ts

[Gerald Hernandez]

Re: Integer Do's And Don'ts

Well, all this discussion has forced me to try to become a little more
informed about how things really are as opposed to how I think they might be
in the future. ;-)

After mulling through much of the CLS docs, I must say I'm leaning more on
the side of the fence with the, obviously more informed, MVP's.

I did find Jay's point about System.IntPtr already being a platform specific
implementation to be a real point of contemplation. The CLS defines the
Primatives very clearly. And the CLS already does define a platform specific
implementation in the IntPtr. This in itself would be a good argument that
the Primitive alias types will probably not change.

Gerald

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:eHhkI75sEH A.3788@TK2MSFTN GP09.phx.gbl...[color=blue]
> Cor,[color=green]
> > I think that in your proposition it is better to use only Int32 than you
> > have no problems with interop or anything else what can lead to
> > misunderstandin g.[/color]
> What are you attempting to say here?
>
> Are you attempting to agree with Ken, Herfried, and I? We have all stated
> that for Interop, with unmanaged code, we use the explicit types. As
> Herfried & I have stated, we do this because the unmanaged sizes might
> change.
>
> For managed code I find Short, Integer, and Long to be the more "explicit"
> types.
>[color=green]
> > But future will tell, now it is academic[/color]
> The future is here today! Whidbey (aka VS.NET 2005, due out later in 2005)
> includes the 64-bit version of the Framework. As Herfried & I have state,
> Integer is still an alias for Int32. I don't see where there is anything
> academic. I am talking existing 64-bit & 32-bit versions of the Framework!
>
> Hope this helps
> Jay
>
> "Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
> news:eD5DXt5sEH A.904@TK2MSFTNG P11.phx.gbl...[color=green]
> > Jay,
> >[color=darkred]
> >>In other words on any size of processor (8, 16, 32, 64, 128, 256) that
> >>VB.NET's Integer is an alias for System.Int32![/color]
> >
> > I think that in your proposition it is better to use only Int32 than you
> > have no problems with interop or anything else what can lead to
> > misunderstandin g.
> >
> > Therefore we disagree in this, I think Microsoft did not advice Integer
> > just for fun.
> >
> > But future will tell, now it is academic
> >
> > Cor
> >[/color]
>
>[/color]

[Cor Ligthert]

Re: Integer Do's And Don'ts

Jay,

It is saterday night here so when I make a mistake do not see it to hard,
Herfied knows what that means for me.
[color=blue]
>
> Are you attempting to agree with Ken, Herfried, and I? We have all stated
> that for Interop, with unmanaged code, we use the explicit types. As
> Herfried & I have stated, we do this because the unmanaged sizes might
> change.[/color]

I do not understand in your statement "Ken" in it, because my fist message
was that I agree with Ken and probably Gerald.

In the situation of interop there is not any discussion at all what I showed
with my statement of comp-3 probably from all the regurlars you and I are
the ones who knows the best what that means. About that point we have no
disagreement at all.

I find Short Integer and Long the most explicit types, that is what I am
telling all the time.

The only thing we disagree is that it is in my opinon 100% sure that Integer
will forever be a 32bits word. There is no need for it as I thought (because
as I stated before I did not investigate that) Gerald showed that ver well.
It can be in a computer that holds a 64bit processor a disadvantage because
there should be a conversion to cut of the first 32bits.

So I think that Integer will be in future a format (set by property or by
default) what will be more normalized to the than used lowest processortype.

I hope that I stated it well although it is saterdaynight here.

Cor

[Cor Ligthert]

Re: Integer Do's And Don'ts

Gerald,

I think we are in one line, I have not seen in this thread that Microsoft
people ever told that Integer will "never" be the same as a 64 or a more
bits processor word.

What I have seen stated in this thread a lot of times, however MVP's do not
represent Microsoft.

I can assure you I would save that statement when it was a guy from
Microsoft who told that.

And do not see this wrong, it is arguing between regulars in this newsgroup
it is not something personal. (Where I am mostly alone against the MVP's,
because I am not a MVP, however that does not shut my mouth so I am glad
with your help).

However in my mind I am sure those regular MVP's from this newsgroup will
support me when it is serious.

:-)

Cor

[Herfried K. Wagner [MVP]]

Re: Integer Do's And Don'ts

Cor,

"Cor Ligthert" <notmyfirstname @planet.nl> schrieb:[color=blue]
> I think we are in one line, I have not seen in this thread that Microsoft
> people ever told that Integer will "never" be the same as a 64 or a more
> bits processor word.
>
> What I have seen stated in this thread a lot of times, however MVP's
> do not represent Microsoft.[/color]

That's a valid point! I must admit that there is no guarantee that
everything I say is right.
[color=blue]
> I can assure you I would save that statement when it was a guy from
> Microsoft who told that.[/color]

:-)

I remember the VB6 -> VB.NET days, when the massive change in the data types
was made for the VB language, and I remember I heard people saying "Never
again!" Language stability of the Visual Basic programming language does
not exist, and that's a shame. I hope Microsoft unterstood that language
stability is a factor that has influence on the choice of a programming
system and programming language, and that Microsoft has learned from the
mistake of changing the meaning of the alias names about two years ago.
[color=blue]
> However in my mind I am sure those regular MVP's from this
> newsgroup will support me when it is serious.
>
> :-)[/color]

It's me who has to say "thank you". Without your messages I wouldn't have
spent as many thoughts on 64-bit .NET and possible language changes...

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Gerald Hernandez]

Re: Integer Do's And Don'ts


"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:%23fdBvm6s EHA.3872@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> Gerald,
>
> I think we are in one line, I have not seen in this thread that Microsoft
> people ever told that Integer will "never" be the same as a 64 or a more
> bits processor word.
>
> What I have seen stated in this thread a lot of times, however MVP's do[/color]
not[color=blue]
> represent Microsoft.
>
> I can assure you I would save that statement when it was a guy from
> Microsoft who told that.
>
> And do not see this wrong, it is arguing between regulars in this[/color]
newsgroup[color=blue]
> it is not something personal. (Where I am mostly alone against the MVP's,
> because I am not a MVP, however that does not shut my mouth so I am glad
> with your help).
>
> However in my mind I am sure those regular MVP's from this newsgroup will
> support me when it is serious.
>
> :-)
>
> Cor
>
>[/color]

[Gerald Hernandez]

Re: Integer Do's And Don'ts

heh, personal? yeah, hopefully no-one thinks these debates are personal.
one of the great, and IMHO fun things, about these groups are the passionate
discussions between the well informed. many might consider me well informed
as well, but I always learn something new from these debates.

someone needs to "stir the pot" in a manner of speaking. if everyone agreed,
it would be a pretty boring planet.

:-)

Gerald


"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:%23fdBvm6s EHA.3872@TK2MSF TNGP15.phx.gbl. ..[color=blue]
> Gerald,
>
> I think we are in one line, I have not seen in this thread that Microsoft
> people ever told that Integer will "never" be the same as a 64 or a more
> bits processor word.
>
> What I have seen stated in this thread a lot of times, however MVP's do[/color]
not[color=blue]
> represent Microsoft.
>
> I can assure you I would save that statement when it was a guy from
> Microsoft who told that.
>
> And do not see this wrong, it is arguing between regulars in this[/color]
newsgroup[color=blue]
> it is not something personal. (Where I am mostly alone against the MVP's,
> because I am not a MVP, however that does not shut my mouth so I am glad
> with your help).
>
> However in my mind I am sure those regular MVP's from this newsgroup will
> support me when it is serious.
>
> :-)
>
> Cor
>
>[/color]

[Mattias Sjögren]

Re: Integer Do's And Don'ts

John,
[color=blue]
>If so, is there a way to remove the ones with size predefined from the
>autolisting of types when I am declaring something?[/color]

If you don't import the System namespace it will not show up. A global
import of System is usually set in the project properties, so make
sure you remove that if you want to get rid of them.



Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Larry Serflaten]

Re: Integer Do's And Don'ts


"Gerald Hernandez" <Cablewizard@sp am_remove@Yahoo .com> wrote
[color=blue]
> And why not? Aliases like this are common in C.
> Hopefully, dotNet will be widely cross platform capable :-)
>
> #If Is64BitSystem Then
> Define Integer = Int64
> #Else
> Define Integer = Int32
> #End If[/color]
<...>[color=blue]
> I know this is relatively foreign to us long time VB users, but makes sense
> to multi-platform developers.[/color]


I dunno if it was all that foreign, VB4 had a lot of that going on, where API's
were available in both the 16 and 32 bit flavors, depending on which platform
was being used. Samples posted anywhere had to account for the difference
in platforms that any potential reader (developer) may be using....

;-)
LFS

[Jay B. Harlow [MVP - Outlook]]

Re: Integer Do's And Don'ts

Herfried,
This does raise an interesting question. We all seem to be assuming that
there will be a 32-bit compiler & a 64-bit compiler in .NET 2.0. I suspect
there will be a single VB.NET compiler (vbc.exe), as I understand there is
going to be a single 32-bit VS.NET, based on the video I posted or an MSDN
article or MSDN Magazine article.

I know the JIT changes based on what platform is deployed, however as you
already stated, the VB compiler already decided on Int32.

I'm not seeing anything obvious in Beta 1 that would either confirm or deny
a single vbc.exe or 2 vbc.exes (it may be too early in the beta).

The way I understand the 64-bit framework itself working (based on the above
video & various MSDN Magazine articles) is that you simply have an assembly,
this assembly is "agnostic" in that it can run on either 32-bit or 64-bit
framework no problem. Or the assembly will bit bit-centric to handle the
cases where you are calling a 32-bit unmanaged API or a 64-bit unmanaged
API.

Thinking about it, I see no real need for a 32-bit specific compiler (C# or
VB.NET) & a specific 64-bit (C# or VB.NET) compiler, as both would simply
create IL for the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT
as the machine instructions needed change. I also see a need for (parts of)
the runtime assemblies changing, as you may need to call a 32-bit or 64-bit
unmanaged API...

The fact the JIT is creating 32-bit or 64-bit machine code is an
implementation detail, that developers do not really need to worry about...

I'll look around the beta to see what I can find...

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:%23H4Ozs5s EHA.3152@TK2MSF TNGP14.phx.gbl. ..[color=blue]
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb:[color=green]
>> As Herfried pointed out, on the 64-bit edition of .NET, currently in
>> Beta.
>> The definition of VB.NET is the same, hence the above definition is the
>> same.[/color]
>
> I don't have a 64-bit machine. AFAIK, applications compiled against the
> 32-bit version of the .NET Framework will work without the need to
> recompilation on 64-bit versions of the .NET Framework.
>
> The mapping 'Integer' -> 'Int32' is done at compile time. The only way I
> see for making 'Integer' to map to 'Int32' is a change in the VB.NET
> compiler's behavior. If the compiler was changed to map 'Integer' to
> 'Int64' on a 64-bit system, then this code won't compile there with
> 'Option
> Strict On', but it will compile with the 32-bit compiler:
>
> \\\
> Dim i As Int32 = ...
> Dim j As Integer = ...
> i = j
> ///
>
> Consequently, I don't see a chance that 'Integer' will ever map to
> 'Int64',
> because this would cause even more confusion and broken code than the
> change
> from VB6 to VB.NET caused.
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Integer Do's And Don'ts

Cor,
One thing I think you are forgetting, that Gerald just reminded me of.

Is that .NET is based on a 'virtual execution system' the CLI (Common
Language Infrastructure) , that the CLI insulates .NET programs from the
underlying operating system.

This operating system could be Windows, Linux, or Mac OS. It could be 32-bit
or 64-bit. Which means it could even be an AS/400 or a IBM MainFrame.

In other words the point of the CLI (.NET) is that your program will run on
what ever platform that has .NET available for it...

For details read the "The Common Language Infrastructure Standard" normally
found at "
\Program Files\Microsoft Visual Studio .NET 2003\SDK\v1.1\T ool Developers
Guide\docs" when you install VS.NET 2003.

Hope this helps
Jay

"Cor Ligthert" <notmyfirstname @planet.nl> wrote in message
news:eD1KUg6sEH A.3052@tk2msftn gp13.phx.gbl...[color=blue]
> Jay,
>
> It is saterday night here so when I make a mistake do not see it to hard,
> Herfied knows what that means for me.
>[color=green]
>>
>> Are you attempting to agree with Ken, Herfried, and I? We have all stated
>> that for Interop, with unmanaged code, we use the explicit types. As
>> Herfried & I have stated, we do this because the unmanaged sizes might
>> change.[/color]
>
> I do not understand in your statement "Ken" in it, because my fist message
> was that I agree with Ken and probably Gerald.
>
> In the situation of interop there is not any discussion at all what I
> showed with my statement of comp-3 probably from all the regurlars you and
> I are the ones who knows the best what that means. About that point we
> have no disagreement at all.
>
> I find Short Integer and Long the most explicit types, that is what I am
> telling all the time.
>
> The only thing we disagree is that it is in my opinon 100% sure that
> Integer will forever be a 32bits word. There is no need for it as I
> thought (because as I stated before I did not investigate that) Gerald
> showed that ver well. It can be in a computer that holds a 64bit processor
> a disadvantage because there should be a conversion to cut of the first
> 32bits.
>
> So I think that Integer will be in future a format (set by property or by
> default) what will be more normalized to the than used lowest
> processortype.
>
> I hope that I stated it well although it is saterdaynight here.
>
> Cor
>
>[/color]

[Herfried K. Wagner [MVP]]

Re: Integer Do's And Don'ts

Jay,

"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb:[color=blue]
> This does raise an interesting question. We all seem to be
> assuming that there will be a 32-bit compiler & a 64-bit
> compiler in .NET 2.0. I suspect there will be a single
> VB.NET compiler (vbc.exe)[/color]

I suspect that too. Only one compiler is needed.
[color=blue]
> as I understand there is going to be a single 32-bit
> VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
> article.[/color]

ACK. From what I have heard, there will be a 32-bit VS 2005 only.
[color=blue]
> I know the JIT changes based on what platform is deployed, however as you[/color]
[color=blue]
> Thinking about it, I see no real need for a 32-bit specific
> compiler (C# or VB.NET) & a specific 64-bit (C# or
> VB.NET) compiler, as both would simply create IL for
> the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
> machine instructions needed change. I also see a
> need for (parts of) the runtime assemblies changing, as you
> may need to call a 32-bit or 64-bit unmanaged API...[/color]

That's what I think too, and that's the reason why I doubt that there will
be a change in the mapping between 'Integer' and 'Int32'.
[color=blue]
> I'll look around the beta to see what I can find...[/color]

:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>

[Jay B. Harlow [MVP - Outlook]]

Re: Integer Do's And Don'ts

Herfried,
I just found this blog "Adventures in the 64bit CLR" in case anyone is
interesting.

http://blogs.msdn.com/joshwil/

Jay

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:Ok0e0OJtEH A.2128@TK2MSFTN GP11.phx.gbl...[color=blue]
> Jay,
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb:[color=green]
>> This does raise an interesting question. We all seem to be
>> assuming that there will be a 32-bit compiler & a 64-bit
>> compiler in .NET 2.0. I suspect there will be a single
>> VB.NET compiler (vbc.exe)[/color]
>
> I suspect that too. Only one compiler is needed.
>[color=green]
>> as I understand there is going to be a single 32-bit
>> VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
>> article.[/color]
>
> ACK. From what I have heard, there will be a 32-bit VS 2005 only.
>[color=green]
>> I know the JIT changes based on what platform is deployed, however as you[/color]
>[color=green]
>> Thinking about it, I see no real need for a 32-bit specific
>> compiler (C# or VB.NET) & a specific 64-bit (C# or
>> VB.NET) compiler, as both would simply create IL for
>> the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
>> machine instructions needed change. I also see a
>> need for (parts of) the runtime assemblies changing, as you
>> may need to call a 32-bit or 64-bit unmanaged API...[/color]
>
> That's what I think too, and that's the reason why I doubt that there will
> be a change in the mapping between 'Integer' and 'Int32'.
>[color=green]
>> I'll look around the beta to see what I can find...[/color]
>
> :-)
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Integer Do's And Don'ts

Herfried,
"vbc /help" in .NET 2.0 beta 1 gives:

/platform:<strin g> Limit which platforms this code can run
on;
must be x86, x64, Itanium or anycpu
(default).

Which is what http://blogs.msdn.com/joshwil/ suggested C# does.

Within VS.NET (beta 1) you can use "Project - Properties - Compile -
Advanced - Target CPU" to change the above setting.

Compiling the following with Target CPU = Itanium (Intel's 64-bit CPU):

Public Class MainForm

Public Shared Sub Main()
Dim index As Integer = 10
index *= 100
End Sub

End Class

Gives the following IL.
..method public static void Main() cil managed
{
.entrypoint
.custom instance void [mscorlib]System.STAThrea dAttribute::.ct or() = ( 01
00 00 00 )
// Code size 11 (0xb)
.maxstack 2
.locals init ([0] int32 index)
.language '{3A12D0B8-C26C-11D0-B442-00A0244A1DD2}',
'{994B45C4-E6E9-11D2-903F-00C04FA302A1}',
'{00000000-0000-0000-0000-000000000000}'
// Source File 'C:\Documents and Settings\Jay\My Documents\Visua l
Studio\Projects \Windows 64 Application\Win dows 64 Application\Mai nForm.vb'
//000009: Public Shared Sub Main()
IL_0000: nop
//000010: Dim index As Integer = 10
IL_0001: ldc.i4.s 10
IL_0003: stloc.0
//000011: index *= 100
IL_0004: ldloc.0
IL_0005: ldc.i4.s 100
IL_0007: mul.ovf
IL_0008: stloc.0
//000012: End Sub
IL_0009: nop
IL_000a: ret
} // end of method MainForm::Main

Which demonstrates, as I was saying: VB.NET defines Integer as an alias for
Sytem.Int32.

Of course I need a Win64 machine to actually execute the above program :-)


Note: The default of AnyCPU for Platform allows your single executable to
run as a 32-bit app on Win32 & a (full!) 64-bit app on Win64! Which IMHO
reinforces the notion that "Integer is an alias for System.Int32" even on
the 64-bit edition of .NET.


Of course if one really needs a platform specific Int, then one could use a
variation of Gerald earlier post.

Something like:

#If Is64BitSystem Then
Imports Int = System.Int64
#Else
Imports Int = System.Int32
#End If

Public Shared Sub Main()
Dim index As Int = 10
index *= 100
End Sub

Of course then you need to be careful of literals (100I verses 100L) and
public methods into & out of your assembly... (all the pain we learned from
C :-))

Alternatively I would consider defining Int as a structure and overload all
the operators. Then compile 3 versions of the assembly with the Int
structure, one for each Target CPU. Which may introduce its own performance
issues, however like System.IntPtr I would only use Int for Interop...


I'm really not sure why there are 2 64-bit targets (x64 & Itanium). I would
expected only one...

Hope this helps
Jay

"Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
news:Ok0e0OJtEH A.2128@TK2MSFTN GP11.phx.gbl...[color=blue]
> Jay,
>
> "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb:[color=green]
>> This does raise an interesting question. We all seem to be
>> assuming that there will be a 32-bit compiler & a 64-bit
>> compiler in .NET 2.0. I suspect there will be a single
>> VB.NET compiler (vbc.exe)[/color]
>
> I suspect that too. Only one compiler is needed.
>[color=green]
>> as I understand there is going to be a single 32-bit
>> VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
>> article.[/color]
>
> ACK. From what I have heard, there will be a 32-bit VS 2005 only.
>[color=green]
>> I know the JIT changes based on what platform is deployed, however as you[/color]
>[color=green]
>> Thinking about it, I see no real need for a 32-bit specific
>> compiler (C# or VB.NET) & a specific 64-bit (C# or
>> VB.NET) compiler, as both would simply create IL for
>> the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
>> machine instructions needed change. I also see a
>> need for (parts of) the runtime assemblies changing, as you
>> may need to call a 32-bit or 64-bit unmanaged API...[/color]
>
> That's what I think too, and that's the reason why I doubt that there will
> be a change in the mapping between 'Integer' and 'Int32'.
>[color=green]
>> I'll look around the beta to see what I can find...[/color]
>
> :-)
>
> --
> Herfried K. Wagner [MVP]
> <URL:http://dotnet.mvps.org/>[/color]

[Gerald Hernandez]

Re: Integer Do's And Don'ts

Thanks, that is a good read.
While I hadn't really considered Integer being Int64 on 64 bit processors in
the near future, it does look like there are some things to consider. It
does look like 2 Int32's will be packed nicely into an Int64, which we all
would expect now. This is a nice change from past platform differences where
a whole Int64 might be allocated for 1 Int32. Guess we need to be aware of
the size of the pointers, which we also knew, but looks like it could raise
it's head in unexpected ways. Gotta watch out how much memory we consume.
Would be a shame to waste half of it due to unneccessary boxing.

I haven't paid much attention to the x64 vs Itanium stuff. But as I
understand it, the x64 is kind of a hybrid processor. It has the 32 Bit
instructions as well as the 64 Bit instructions. Also supports both memory
pipelines. The Itanium has it's own set of 64 Bit instructions, and only
those. So in the long run it looks like it might die due to compatibility
issues.

Gerald


"Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> wrote in message
news:OszJX1KtEH A.3972@TK2MSFTN GP15.phx.gbl...[color=blue]
> Herfried,
> "vbc /help" in .NET 2.0 beta 1 gives:
>
> /platform:<strin g> Limit which platforms this code can run
> on;
> must be x86, x64, Itanium or anycpu
> (default).
>
> Which is what http://blogs.msdn.com/joshwil/ suggested C# does.
>
> Within VS.NET (beta 1) you can use "Project - Properties - Compile -
> Advanced - Target CPU" to change the above setting.
>
> Compiling the following with Target CPU = Itanium (Intel's 64-bit CPU):
>
> Public Class MainForm
>
> Public Shared Sub Main()
> Dim index As Integer = 10
> index *= 100
> End Sub
>
> End Class
>
> Gives the following IL.
> .method public static void Main() cil managed
> {
> .entrypoint
> .custom instance void [mscorlib]System.STAThrea dAttribute::.ct or() = ([/color]
01[color=blue]
> 00 00 00 )
> // Code size 11 (0xb)
> .maxstack 2
> .locals init ([0] int32 index)
> .language '{3A12D0B8-C26C-11D0-B442-00A0244A1DD2}',
> '{994B45C4-E6E9-11D2-903F-00C04FA302A1}',
> '{00000000-0000-0000-0000-000000000000}'
> // Source File 'C:\Documents and Settings\Jay\My Documents\Visua l
> Studio\Projects \Windows 64 Application\Win dows 64 Application\Mai nForm.vb'
> //000009: Public Shared Sub Main()
> IL_0000: nop
> //000010: Dim index As Integer = 10
> IL_0001: ldc.i4.s 10
> IL_0003: stloc.0
> //000011: index *= 100
> IL_0004: ldloc.0
> IL_0005: ldc.i4.s 100
> IL_0007: mul.ovf
> IL_0008: stloc.0
> //000012: End Sub
> IL_0009: nop
> IL_000a: ret
> } // end of method MainForm::Main
>
> Which demonstrates, as I was saying: VB.NET defines Integer as an alias[/color]
for[color=blue]
> Sytem.Int32.
>
> Of course I need a Win64 machine to actually execute the above program :-)
>
>
> Note: The default of AnyCPU for Platform allows your single executable to
> run as a 32-bit app on Win32 & a (full!) 64-bit app on Win64! Which IMHO
> reinforces the notion that "Integer is an alias for System.Int32" even on
> the 64-bit edition of .NET.
>
>
> Of course if one really needs a platform specific Int, then one could use[/color]
a[color=blue]
> variation of Gerald earlier post.
>
> Something like:
>
> #If Is64BitSystem Then
> Imports Int = System.Int64
> #Else
> Imports Int = System.Int32
> #End If
>
> Public Shared Sub Main()
> Dim index As Int = 10
> index *= 100
> End Sub
>
> Of course then you need to be careful of literals (100I verses 100L) and
> public methods into & out of your assembly... (all the pain we learned[/color]
from[color=blue]
> C :-))
>
> Alternatively I would consider defining Int as a structure and overload[/color]
all[color=blue]
> the operators. Then compile 3 versions of the assembly with the Int
> structure, one for each Target CPU. Which may introduce its own[/color]
performance[color=blue]
> issues, however like System.IntPtr I would only use Int for Interop...
>
>
> I'm really not sure why there are 2 64-bit targets (x64 & Itanium). I[/color]
would[color=blue]
> expected only one...
>
> Hope this helps
> Jay
>
> "Herfried K. Wagner [MVP]" <hirf-spam-me-here@gmx.at> wrote in message
> news:Ok0e0OJtEH A.2128@TK2MSFTN GP11.phx.gbl...[color=green]
> > Jay,
> >
> > "Jay B. Harlow [MVP - Outlook]" <Jay_Harlow_MVP @msn.com> schrieb:[color=darkred]
> >> This does raise an interesting question. We all seem to be
> >> assuming that there will be a 32-bit compiler & a 64-bit
> >> compiler in .NET 2.0. I suspect there will be a single
> >> VB.NET compiler (vbc.exe)[/color]
> >
> > I suspect that too. Only one compiler is needed.
> >[color=darkred]
> >> as I understand there is going to be a single 32-bit
> >> VS.NET, based on the video I posted or an MSDN article or MSDN Magazine
> >> article.[/color]
> >
> > ACK. From what I have heard, there will be a 32-bit VS 2005 only.
> >[color=darkred]
> >> I know the JIT changes based on what platform is deployed, however as[/color][/color][/color]
you[color=blue][color=green]
> >[color=darkred]
> >> Thinking about it, I see no real need for a 32-bit specific
> >> compiler (C# or VB.NET) & a specific 64-bit (C# or
> >> VB.NET) compiler, as both would simply create IL for
> >> the Framework. I do see a need for a 64-bit JIT & a 32-bit JIT as the
> >> machine instructions needed change. I also see a
> >> need for (parts of) the runtime assemblies changing, as you
> >> may need to call a 32-bit or 64-bit unmanaged API...[/color]
> >
> > That's what I think too, and that's the reason why I doubt that there[/color][/color]
will[color=blue][color=green]
> > be a change in the mapping between 'Integer' and 'Int32'.
> >[color=darkred]
> >> I'll look around the beta to see what I can find...[/color]
> >
> > :-)
> >
> > --
> > Herfried K. Wagner [MVP]
> > <URL:http://dotnet.mvps.org/>[/color]
>
>[/color]

[Jay B. Harlow [MVP - Outlook]]

Re: Integer Do's And Don'ts

Gerald,[color=blue]
> I haven't paid much attention to the x64 vs Itanium stuff. But as I
> understand it, the x64 is kind of a hybrid processor. It has the 32 Bit
> instructions as well as the 64 Bit instructions.[/color]
I believe you may be correct. However! VB.NET & C# compiles down to IL, IL
is platform agnostic. As far as I know the only real reason you need to know
the platform is P/Invoke (the marshaller needs to know how to package the
parameters).

I would expect P/Invoke to be largely agnostic also, in that its just a
Thunk to the real API. In other words the JIT &
System.Runtime. InteroprService s class resolve any calling convention
differences, the IL is an abstraction that shouldn't care if you are a
hybrid process or not...

In other words I can understand platform = 32bit or 64bit or Any, I just
haven't seen the explanation on why both x64 & Itanium...
[color=blue]
> Gotta watch out how much memory we consume.[/color]
Just Remember the 80/20 rule. That is 80% of the execution time of your
program is spent in 20% of your code. I will optimize (worry about
performance, memory consumption) the 20% once that 20% has been identified &
proven to be a performance problem via profiling (CLR Profiler is one
profiling tool).

For info on the 80/20 rule & optimizing only the 20% see Martin Fowler's
article "Yet Another Optimization Article" at

http://martinfowler.com/ieeeSoftware/yetOptimization.pdf

[color=blue]
> Would be a shame to waste half of it due to unneccessary boxing.[/color]
Unnecessary boxing can be a bad idea even in the 32-bit world! Which is why
the new Generic collection classes
(http://msdn2.microsoft.com/library/0sbxh9x2.aspx) will be very handy
indeed. I normally try to apply the 80/20 rule on deciding if I want to use
an array of value types or an Arraylist of value types. With .NET 2.0 & the
Generic collection classes I may simply favor the Generic collection
classes, unless they, via profiling are shown to be a performance issue for
a specific routine...

Hope this helps
Jay




"Gerald Hernandez" <Cablewizard@sp am_remove@Yahoo .com> wrote in message
news:%23TkML%23 LtEHA.3412@TK2M SFTNGP14.phx.gb l...[color=blue]
> Thanks, that is a good read.
> While I hadn't really considered Integer being Int64 on 64 bit processors
> in
> the near future, it does look like there are some things to consider. It
> does look like 2 Int32's will be packed nicely into an Int64, which we all
> would expect now. This is a nice change from past platform differences
> where
> a whole Int64 might be allocated for 1 Int32. Guess we need to be aware of
> the size of the pointers, which we also knew, but looks like it could
> raise
> it's head in unexpected ways. Gotta watch out how much memory we consume.
> Would be a shame to waste half of it due to unneccessary boxing.
>
> I haven't paid much attention to the x64 vs Itanium stuff. But as I
> understand it, the x64 is kind of a hybrid processor. It has the 32 Bit
> instructions as well as the 64 Bit instructions. Also supports both memory
> pipelines. The Itanium has it's own set of 64 Bit instructions, and only
> those. So in the long run it looks like it might die due to compatibility
> issues.
>
> Gerald
>
>[/color]
<<snip>>