Integer Do's And Don'ts

[Cor Ligthert]

"Herfried K. Wagner [MVP]"

The choice of a data type should /not/ be made with the processor
architecture and hardware features in mind, instead it should be made
based
on the context of the programming problem that should be solved.

http://www.hut.fi/Misc/cbm/

You are your whole live with the 32bit computer I see as some people stayed
there whole live with this computer above

This are not the types where I had to start programming with by the way that
were this ones
http://www.liceofoscarini.it/didattic/calcolo/ibm360.html

You can read Italian so that will not be a problem. (I thought that I
started with a 8Kb one)

Cor

 

[Larry Serflaten]

The choice of a data type should /not/ be made with the processor
architecture and hardware features in mind, instead it should be made based
on the context of the programming problem that should be solved.

That is in opposition to the advice that says loop counters, especially
those that need performance, should be of the native type to the system.

So many rules, so little time...

<g>
LFS

 

[Cor Ligthert]

Larry,

Future will tell, however in my opinion holds an Integer a complete word.

For me does that means a complete register word from the processor what is
the best format to use in a computer for calculations because there is not
any extra processing needed.

In my idea are you mixing that up with a byte, a byte is a format as it is
used in memory or on disk.

Cor

 

[Herfried K. Wagner [MVP]]

That is in opposition to the advice that says loop counters, especially
those that need performance, should be of the native type to the system.

So we need to update our code every time there is a technology shift....

\\\
#If Is64BitSystem Then
Dim i As Long
#Else
Dim i As Integer
#End If
For i = 1 To 10
...
Next i
///

.... or...

\\\
If System.Is64Bit Then
For i As Long = 1 To 10
...
Next i
Else
For i As Integer = 1 To 10
...
Next i
End If
///

Reminds me of weird C++ code that needs to be run on multiple hardware/os
platforms...

SCNR

 

[Jay B. Harlow [MVP - Outlook]]

John,
In addition to the other comments.

VB.NET has defined Integer to be an alias for System.Int32. With VS.NET 2005
64-bit edition (currently in beta, due out later in 2005), VB.NET has
defined Integer to be an alias for System.Int32, I would not worry about the
size of Integer "magically" changing as it did from VB6 to VB.NET.

I do as Herfried does for purely managed code I use Integer, Short, Long.

When I am declaring interfaces & methods used in COM & Win32 Interop I will
use the more explicit Int32.

Hope this helps
Ja

 

[Larry Serflaten]

In my idea are you mixing that up with a byte, a byte is a format as it is
used in memory or on disk.

And if an Integer is 2 bytes, and a Long 4 bytes, as was the case in VB6,
isn't that also a decription of their format? A lot of developers thought so....

LFS

 

[Herfried K. Wagner [MVP]]

Future will tell, however in my opinion holds an Integer a
complete word.

That may be true, but I think that is not what Larry and I are trying to
tell you. There are two different questions:

Q: Will an 'Int32' require 64 bits on a 64-bit system?
A: I assume that this will be the case, but I am not a hardware specialist.

Q: Will 'Integer' change its semantics on a 64-bit system?
A: Definitely no. An 'Integer' on a 64-bit system will have the same
range/number of representable numbers. The underlying hardware/system will
be completely transparent to the programmer, no changes in (managed) code
are required.

For me does that means a complete register word from the
processor what is the best format to use in a computer for
calculations because there is not any extra processing needed.

For me, a "word" is 16 bits, thus a VB.NET 'Integer' is a "dword", which
means that it's a 32-bit integer number.

 

[Cor Ligthert]

Herfried,

That may be true, but I think that is not what Larry and I are trying to
tell you. There are two different questions:

Q: Will an 'Int32' require 64 bits on a 64-bit system?
A: I assume that this will be the case, but I am not a hardware
specialist.

No of course not, I am talking about an Integer not an Int32 which describe
a special format.

Q: Will 'Integer' change its semantics on a 64-bit system?
A: Definitely no. An 'Integer' on a 64-bit system will have the same
range/number of representable numbers. The underlying hardware/system
will
be completely transparent to the programmer, no changes in (managed) code
are required.

This I said I will let now to the future

For me, a "word" is 16 bits, thus a VB.NET 'Integer' is a "dword", which
means that it's a 32-bit integer number.

I hope we both will see in future



Cor

 

[Cor Ligthert]

Jay,

Nothing different than I wrote.



Cor

 

[Gerald Hernandez]

Cor,

Yes, my exceptions would be the same as Ken, we are saying the same thing.
If interoperting with unmanaged code, I explictly define size.
If reading from binary file, where format might be Int16, Int32, instead of
using Short, Integer, I play it safe and use the explicit types. Right now,
they are functionally identical. But what about 5 years from now?

As this discussion shows, there is confusion as to what might happen in the
future with the Aliased names (Integer, Short, etc). The arguments on both
sides make a lot of sense. But I have seen nothing definative. And with the
change from VB6 to VB.Net, the original argument of Integer maybe changing
to something else seems like a possibility in the future.

As best I can tell, Ken seems to be of the opinion that the alias Integer
will always map to Int32, and he may be correct. But I also note that he too
plays it smart, and also to be explicit, and does not use the alias when
calling unmanaged code.

Gerald

John,

Because there are different opinions, I go for as far as now posted Ken.
What is almost the same as for Gerald, however your question was Integer not
any other special format that has to be used, because it is needed in that
special format, so I am not sure what he mean with that, however I think the
same as Ken and me.

The Integer keyword ensures you that after recompiling the machine most
properiate format is used. Any other format can lead (now or in future) to
extra processing time when it is not optimized by the compiler.

Just my thought

Cor

 

[Herfried K. Wagner [MVP]]

That may be true, but I think that is not what Larry and I are trying to
tell you. There are two different questions:
[...]
Q: Will 'Integer' change its semantics on a 64-bit system?
A: Definitely no. An 'Integer' on a 64-bit system will have the same
range/number of representable numbers. The underlying
hardware/system will be completely transparent to the programmer,
no changes in (managed) code are required.

This I said I will let now to the future

There are already preview versions of the 64-bit version of the framework
available, and in these versions, 'Integer' maps to 'Int32', as it is
documented in the documentation for the 'Int32' type. There is absolutely
not reason to change the mapping between 'Integer' -> 'Int32' into
'Integer' -> 'Int64' for 64-bit system. This change would only have
disadvantages such as broken code.

 

[Cor Ligthert]

Correction it is in opposite with my explanation.

I did tell in this long thread that using there where it is possible Integer
is the best way to go for future compatiblity with the size of the
processor.

That has nothing to do with the next version. Can be the successor as well
or even that successor. When the language change completly than that has
been for nothing however it stays the best way in my opinion.

This you can see with coverted VB6 programs as is shown in this thread which
now use the best processor format for processing when there was used
Integer and not the Int16.

Wich has nothing to do when you need the format of a delivering program (or
interface or whatever). Than you cannot do anything else than use that
format. Even when it would be something that fits to comp-3 when that is
needed.

However you are free to disagree this with me, where I by myself think you
are not.

Cor

 

[Gerald Hernandez]

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

Dim i as Integer 'Could be Int32 or Int64
For I = 1 to 10
...
Next I

I know this is relatively foreign to us long time VB users, but makes sense
to multi-platform developers.

Gerald

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
You may want to read my post again!

I stated what Herfried stated, what you stated is:

<quote source="Cor">
The Integer keyword ensures you that after recompiling the machine most
properiate format is used. Any other format can lead (now or in future) to
extra processing time when it is not optimized by the compiler.
</quote>

You stated "machine most propertirate format is used" I did not state
anything close to that. In fact I may be stating the opposite.

I stated that Integer is an alias for Sytem.Int32.

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!

Hope this helps
Jay

 

[Gerald Hernandez]

I sort of agree with you Cor, so you are not alone.
I truly do not know what will happen in the future.
But it would make sense to me that the aliases "could" and maybe even
"should" change based upon the most efficient use of the platform.
However, it is entirely possible that it will never change.
So I sit right on the middle of the fence.

With all the disagreement about what the future may hold, we all seem to
agree on the following.
Even though we all know with certainty that Integer maps to Int32, when we
know we need a specific number of bits, such as calling unmanaged code, we
all seem to use the Int32 convention.
In managed code, if we just need an integer, presumably 32 bits, we use the
Integer alias.
In the future, this may or may not change to 64 bits. But would be at least
32 bits, so code should not break.

Gerald

 

[Gerald Hernandez]

Ah yes, this is a good point.
No matter what the future may hold, currently Integer will always map to
Int32.
In the future, maybe that will change, but AFAIK currently none of the
proposed platform "optimizations" exist.

Gerald

 

[Jay B. Harlow [MVP - Outlook]]

Cor,
I am not referring to VB6 programs, I am talking about VB.NET.

See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vblr7/html/vadatInteger.asp

<quote>
Integer ... The equivalent .NET data type is System.Int32
</quote>

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.

Hope this helps
Jay

 

[Jay B. Harlow [MVP - Outlook]]

Gerald,

And why not? Aliases like this are common in C.

Oddly enough that is my understanding why they DON'T do it! How that saying
go "If you don't remember your history you are bound to repeat it"?

As Larry stated, if you need a "platform-specific type that is used to
represent a pointer or a handle" then you can use System.IntPtr or
System.UIntPtr.

http://msdn.microsoft.com/library/d...us/cpref/html/frlrfSystemIntPtrClassTopic.asp

http://msdn.microsoft.com/library/d...s/cpref/html/frlrfSystemUIntPtrClassTopic.asp

Hopefully, dotNet will be widely cross platform capable

There is a Linux/Mac OS version available
http://www.mono-project.com/about/index.html

Microsoft's 64-bit version of .NET is currently in beta as part of VS.NET
2005 (due out later in 2005). I understand that most current .NET programs
will run on the 64-bit version will little or no modification... 64-bit
specific newsgroups available at
http://communities.microsoft.com/newsgroups/default.asp?icp=whidbey&amp;slcid=us

Hope this helps
Jay

 

[Herfried K. Wagner [MVP]]

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.

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.

 

[Cor Ligthert]

Jay,

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!

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
misunderstanding.

Therefore we disagree in this, I think Microsoft did not advice Integer just
for fun.

But future will tell, now it is academic

Cor