Integer Do's And Don'ts

[John Baker]

When declaring an integer, you can specify the size by using int16,
int32, or int64, with plain integer being int32.

Is integer the accepted default in the programming community?

If so, is there a way to remove the ones with size predefined from the
autolisting of types when I am declaring something?

 

[Ken Dopierala Jr.]

Hi,

I don't think you can remove them from the drop down. The best bet is to
use just plain Integer. That will assure that you are using a 32-bit
integer and right now it is the fastest because it plays well with 32bit
boundaries that are using in 32bit programming models. If you are going to
mix them up then remember to put Option Strict On at the top of your code
pages. This will save you headaches when it comes to converting between
them in calculations and assignments. Good luck! Ken.

 

[Gerald Hernandez]

At one time I got the impression that Integer was a generic term that would
map to the native integer size of the environment in which you were running.
There was also some sort of guarantee that it would not be smaller than
Int32. This would ensure you would get the best performance if you did not
need a particular size.
In the future, Integer might map to Int64, Long might map to Int128, or
whatever.

However, I have also read a number of things countering this saying Integer
will always map to Int32. The first argument made more sense to me, but I
truly do not know the future plans.

But to be on the safe side, here is what I do.
If all I need is a generic integer of at least size Int32, then just use the
Integer keyword, which is almost always the case.
If I am dealing with things like bit-fields or reading datablocks from files
that I know are a specific size, then I explicitly declare the integer size.

Gerald

 

[Herfried K. Wagner [MVP]]

When declaring an integer, you can specify the size by using int16,
int32, or int64, with plain integer being int32.

Is integer the accepted default in the programming community?

There are different standpoints on the question of preferring the aliases
over the type names as they can be found in the .NET Framework.

Personally, I use 'Integer', 'Short', ... when I am writing fully managed
code. When interoperating with unmanaged code, I prefer the more low-level
names, 'Int32', 'Int16', ...

If so, is there a way to remove the ones with size predefined from the
autolisting of types when I am declaring something?

No.

 

[Cor Ligthert]

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

 

[Larry Serflaten]

The Integer keyword ensures you that after recompiling the machine most
properiate format is used.

Is that documented? Where?

LFS

 

[Cor Ligthert]

Larry,

Is that documented? Where?

Larry read the answer again, there is in my opinion not any need for
documentation, do you think that Int16 ensures you that (read in the
question as well and see that we are talking about integers).

Cor

 

[Cor Ligthert]

Larry,

When sending my previous answer about CDate to somebody else, I remembered
me that it is documented in this page.

This is the text
Data Type Width
The most efficient data types are those that use the native data width of
the run-time platform. On current platforms, the data width is 32 bits, for
both the computer and the operating system.

Consequently, Integer is currently the most efficient data type in Visual
Basic .NET. Next best are Long, Short, and Byte, in that order of
efficiency. You can improve the performance of Short and Byte by turning off
integer overflow checking, for example by setting the RemoveIntegerChecks
property, but this incurs the risk of incorrect calculations due to
undetected overflows. You cannot toggle this checking on and off during run
time; you can only set its value for the next build of your application.

If you need fractional values, the best choice is Double, because the
floating-point processors of current platforms perform all operations in
double precision. Next best are Single and Decimal, in that order of
efficiency.

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dv_vstechart/html/vbtchPerfOpt.asp

I hope this is where you are looking for when your question was purely about
the documentation and not for discussion.

Cor

 

[Herfried K. Wagner [MVP]]

Larry,

Is that documented? Where?

Nope. 'Integer' always maps to 'System.Int32'. That's documented here:

Visual Basic Language Reference -- 'Integer' Data Type
<URL:http://msdn.microsoft.com/library/en-us/vblr7/html/vadatinteger.asp>

 

[Larry Serflaten]

The most efficient data types are those that use the native data width of
the run-time platform.

Consequently, Integer is currently the most efficient data type in Visual
Basic .NET.

But that does not say what you indicated, that using Integer will ensure you get
the most efficient (native) type. An Integer is always 32 bits on every system:

"Integer variables are stored as signed 32-bit (4-byte) integers ranging in value from -2,147,483,648 through 2,147,483,647"


The only two that I have heard of, that do change on different systems is
the IntPtr and UIntPtr types:

"The IntPtr type is designed to be an integer whose size is platform-specific. That is, an instance of this type is expected to
be 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit hardware and operating systems."

HTH
LFS

 

[Cor Ligthert]

Hi Herfried,

For the current Net version, nothing is said that the Integer will not
called in a computer with a 64bit register to that which is than a Int64

And because it is not done you will never find any open documentation from
Microsoft on that.

Cor

 

[Herfried K. Wagner [MVP]]

For the current Net version, nothing is said that the Integer will not
called in a computer with a 64bit register to that which is than a Int64

Even on 64-bit systems, 'Integer' will be an alias for 'Int32'. Otherwise
the same confision caused with the transition from VB6 to VB.NET 2002 would
resurrect...

<URL:http://groups.google.de/[email protected]
..gbl>

 

[Cor Ligthert]

Larry,

Yes, did you see that text on the link I showed you? It would be different
when if Net could work on 8088 or 8086 computers.

But that does not say what you indicated, that using Integer will ensure
you get
the most efficient (native) type. An Integer is always 32 bits on every
system:

Are you sure of that in a 8088 the register holds only 8 bits words and on
the 8086 it was 16 bits. Therefore the Int16 should be the best type on the
8086.

On currenct computer which run Microsoft Net it is 32 bits, so any other
format needs extra processing. (Not talking about 64bits see for that
beneath)

The only two that I have heard of, that do change on different systems is
the IntPtr and UIntPtr types:

"The IntPtr type is designed to be an integer whose size is
platform-specific. That is, an instance of this type is expected to
be 32-bits on 32-bit hardware and operating systems, and 64-bits on 64-bit
hardware and operating systems."

See this for the Int64
http://msdn.microsoft.com/library/d...-us/cpref/html/frlrfsystemint64classtopic.asp

I am talking how the processor acts with it on a 64bits computer will any
64bit format be the most efficient and I assume that future VSNet will
optimize for that when the Integer is used.

Cor

 

[Cor Ligthert]

Hi Herfried,

Even on 64-bit systems, 'Integer' will be an alias for 'Int32'. Otherwise
the same confision caused with the transition from VB6 to VB.NET 2002
would
resurrect...

Than there would not be a need to call it Integer and is Int32 sufficient
and be a big stuppidity of Microsoft, I think they are not.

In most good compilers there where always option settings to exclude older
processor types and with that optimize the code, I assume that this will be
with this as well in future.

Cor

 

[Larry Serflaten]

Yes, did you see that text on the link I showed you? It would be different
when if Net could work on 8088 or 8086 computers.

No, it would not be different.

Are you sure of that in a 8088 the register holds only 8 bits words and on
the 8086 it was 16 bits. Therefore the Int16 should be the best type on the
8086.

Correct, but if VB.Net was running on that 8086, an Integer would still be 32 bits.

See this for the Int64
http://msdn.microsoft.com/library/d...-us/cpref/html/frlrfsystemint64classtopic.asp

Did you see this:

"Represents a 64-bit signed integer."


The size of a bit will not change, and Int64 uses 64 of them, that will not
change, it says so, at the very top of the document, an Int64 is a 64-bit
signed integer. 64 bits now, and 64 bits later.... Now go look at Integer!

http://msdn.microsoft.com/library/en-us/vblr7/html/vadatInteger.asp

"Integer variables are stored as signed 32-bit (4-byte) integers"

It says Integer uses 32 bits. It does not say is uses the best size
for the platform, it uses 32 bits. A bit will not change, and it uses 32
of them.

I am talking how the processor acts with it on a 64bits computer will any
64bit format be the most efficient and I assume that future VSNet will
optimize for that when the Integer is used.

No, Integer will be 32 bits on a 64 bit system.

Imagine, if Integer moved to 64 bits, what will Long be? And if
Long moves to 128 bits does that mean a Byte type should move too?

The bit sizes are fixed on all but two types (IntPtr, IntPtr).

(Read those in Help...)
LFS

 

[Cor Ligthert]

Larry,

Correct, but if VB.Net was running on that 8086, an Integer would still be
32 bits.

Why are you some defintive in this, do you have some documentation I do not
have?

You show me a page where it is even written that the value of an Integer in
VB6 was 16bits (based on 16bits register most probably what was in past
needed, however not now because Microsoft Net is not running on 16bit
computers)

Where do I not understand you.

This page shows what I am telling in this thread. And still you say that
Integer is a fixed word for Int32.

Cor

 

[Herfried K. Wagner [MVP]]

Why are you some defintive in this, do you have some documentation I do not
have?

It would be still 32-bit, with the same semantics of the 'System.Int32'
type, because it will be the same type.

You show me a page where it is even written that the value of an Integer in
VB6 was 16bits (based on 16bits register most probably what was in past
needed, however not now because Microsoft Net is not running on 16bit
computers)

There was a lot of discussion about renaming the datatypes, and it was IMO a
bad idea to do that because it broke language stability. But that's another
topic. VB6 and VB.NET cannot be compared, and it's irrelevant what aliases
there are defined for a certain CTS type ('System.Int32'). In C# it's
'int', in VB.NET it's 'Integer', independent from the processor/register
architecture of the system the application is running on.

I agree that there may be a negative impact when running an application that
makes extensive use of 'Integer' (= 'Int32') on an 8-bit machine, for
example. Nevertheless, this doesn't change anything with the 'Integer' (=
'Int32') data type.

This page shows what I am telling in this thread. And still you say that
Integer is a fixed word for Int32.

The page clearly says "Integer variables are stored as signed 32-bit
(4-byte) integers". It doesn't take account of the underlying
implementation that may store the value as 4 bytes in a 64-bit register.
Running a .NET application simply won't require any additional
considerations for a programmer who uses 'Integer', because 'Integer' will
still have its 32-bit integer semantics, and not 64-but integer semantics.

 

[JD]

In the .NET type system there is no such type as "Integer", they are Int8,
Int16, Int32, Int64. Brad Abrams wrote its up to the specific language
implementation to map "Integer" to the specific integer size in the .NET
type system. VB specification clearly states that Integer will mapped to
Int32. Whether that changes or not is up to the language, not the .NET type
system.

JD

 

[Herfried K. Wagner [MVP]]

In the .NET type system there is no such type as "Integer", they are Int8,
Int16, Int32, Int64. Brad Abrams wrote its up to the specific language
implementation to map "Integer" to the specific integer size in the .NET
type system.

That's true.

VB specification clearly states that Integer will mapped to
Int32. Whether that changes or not is up to the language, not the .NET type
system.

Changing a datatype's semantics will break existing code (see transition
from VB6 -> VB.NET). So it's very unlikely that the mapping 'Integer' ->
'Int32' will ever change in VB.NET, and there is absolutely no indication
that it will change in future.

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.

 

[Larry Serflaten]

Why are you some defintive in this, do you have some documentation I do not
have?

Did you not hear the large outcry when developers first learned that
..Net Integer would be 32 bits??? How many bits does a VB6 Byte have?
How many are there in VB.Net? What do you suppose would happen if
MSFT decided that a Byte in VB.Net now has 16 bits?

The data type names have been the same since version 1. Now in VB.Net
they changed the number of bits and developers did not like it. Why did
they not change the Byte type? Instead they added a new type in place
of VB6 Integers, a 2 byte Short. Why did they not change Byte to 16 bits?

The reason is because the name is supposd to identify the type of data that
the variable can hold. A Byte holds 0-255, a Short is 2 bytes, and an
Integer is 4 bytes. Is a byte going to change for 64 systems, - not very likely.

You show me a page where it is even written that the value of an Integer in
VB6 was 16bits
http://msdn.microsoft.com/library/en-us/vbenlr98/html/vagrpDataType.asp


Where do I not understand you.

This page shows what I am telling in this thread. And still you say that
Integer is a fixed word for Int32.

I would like to say that, but I cant....
As we saw from VB6 to VB.Net, Microsoft can do whatever they want.
I am saying that _most developers_ expect Integer will remain fixed to an
Int32. No one can be sure what MSFT will decide to do....

Have you not noticed that (Microsoft specific) C++ names did not change
in the move from 16 to 32 bit systems? They will not change in size from
32 to 64 either. The names are associated with the size, that is what is expected.

While the C++ language specifies integral names, Microsoft has specific names
that do not change size on different systems. That is what developers expect
from VB. That is how it should be, but no one can say how it will be when
Microsoft can do whatever they feel is in their own best interest....

LFS