469,280 Members | 2,283 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,280 developers. It's quick & easy.

Integer Do's And Don'ts

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?
--
To Email Me, ROT13 My Shown Email Address

Nov 21 '05 #1
61 2850
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.

--
Ken Dopierala Jr.
For great ASP.Net web hosting try:
http://www.webhost4life.com/default.asp?refid=Spinlight
If you sign up under me and need help, email me.

"John Baker" <wb********@wzwfreivprf.pbz> wrote in message
news:Sy*****************@fe1.columbus.rr.com...
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?
--
To Email Me, ROT13 My Shown Email Address

Nov 21 '05 #2
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

"John Baker" <wb********@wzwfreivprf.pbz> wrote in message
news:Sy*****************@fe1.columbus.rr.com...
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?
--
To Email Me, ROT13 My Shown Email Address

Nov 21 '05 #3
"John Baker" <wb********@wzwfreivprf.pbz> schrieb:
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.

--
Herfried K. Wagner [Microsoft MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #4
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

"John Baker" <wb********@wzwfreivprf.pbz>
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?
--
To Email Me, ROT13 My Shown Email Address

Nov 21 '05 #5

"Cor Ligthert" <no************@planet.nl> wrote
The Integer keyword ensures you that after recompiling the machine most
properiate format is used.

Is that documented? Where?

LFS
Nov 21 '05 #6
Larry,
The Integer keyword ensures you that after recompiling the machine most
properiate format is used.


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
Nov 21 '05 #7
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/de...tchPerfOpt.asp

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

Cor
Nov 21 '05 #8
Larry,

"Larry Serflaten" <se*******@usinternet.com> schrieb:
The Integer keyword ensures you that after recompiling the machine most
properiate format is used.


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>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #9

"Cor Ligthert" <no************@planet.nl> wrote

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

Nov 21 '05 #10
Hi Herfried,
Nope. 'Integer' always maps to 'System.Int32'. That's documented here:


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
Nov 21 '05 #11
"Cor Ligthert" <no************@planet.nl> schrieb:
Nope. 'Integer' always maps to 'System.Int32'. That's
documented here:


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/groups?selm=...2MSFTNGP12.phx
..gbl>

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #12
Larry,
Consequently, Integer is currently the most efficient data type in Visual
Basic .NET.

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/de...classtopic.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

Nov 21 '05 #13
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


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
Nov 21 '05 #14

"Cor Ligthert" <no************@planet.nl> wrote
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.

But that does not say what you indicated,

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/de...classtopic.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...datInteger.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

Nov 21 '05 #15
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
Nov 21 '05 #16
"Cor Ligthert" <no************@planet.nl> schrieb:
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?
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #17
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:eM****************@TK2MSFTNGP14.phx.gbl...
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
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

Nov 21 '05 #18
"JD" <no@address.org> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #19

"Cor Ligthert" <no************@planet.nl> wrote

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?


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...rpDataType.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
Nov 21 '05 #20

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote
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
Nov 21 '05 #21
"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/didatti...lo/ibm360.html

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

Cor

Nov 21 '05 #22
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
Nov 21 '05 #23
"Larry Serflaten" <se*******@usinternet.com> schrieb:
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 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

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #24

"Cor Ligthert" <no************@planet.nl> wrote
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
Nov 21 '05 #25
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

"John Baker" <wb********@wzwfreivprf.pbz> wrote in message
news:Sy*****************@fe1.columbus.rr.com...
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?
--
To Email Me, ROT13 My Shown Email Address

Nov 21 '05 #26
"Cor Ligthert" <no************@planet.nl> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #27
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 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.


I hope we both will see in future

:-)

Cor
Nov 21 '05 #28
Jay,

Nothing different than I wrote.

:-)

Cor
Nov 21 '05 #29
"Cor Ligthert" <no************@planet.nl> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #30
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:eT**************@tk2msftngp13.phx.gbl...
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

"John Baker" <wb********@wzwfreivprf.pbz>
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?
--
To Email Me, ROT13 My Shown Email Address


Nov 21 '05 #31
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
Nov 21 '05 #32
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uz**************@TK2MSFTNGP09.phx.gbl...
"Larry Serflaten" <se*******@usinternet.com> schrieb:
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 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

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

Nov 21 '05 #33
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
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Jay,

Nothing different than I wrote.

:-)

Cor

Nov 21 '05 #34
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...
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

Nov 21 '05 #35
Cor,
I am not referring to VB6 programs, I am talking about VB.NET.

See:
http://msdn.microsoft.com/library/de...datInteger.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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:OV**************@TK2MSFTNGP10.phx.gbl...
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

Nov 21 '05 #36
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]" <Ja************@msn.com> wrote in message
news:uv**************@tk2msftngp13.phx.gbl...
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
"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP09.phx.gbl...
Jay,

Nothing different than I wrote.

:-)

Cor


Nov 21 '05 #37
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/de...ClassTopic.asp

http://msdn.microsoft.com/library/de...ClassTopic.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/new...y&amp;slcid=us

Hope this helps
Jay

"Gerald Hernandez" <Cablewizard@sp*********@Yahoo.com> wrote in message
news:u$**************@TK2MSFTNGP12.phx.gbl... 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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uz**************@TK2MSFTNGP09.phx.gbl...
"Larry Serflaten" <se*******@usinternet.com> schrieb:
> > 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 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

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


Nov 21 '05 #38
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
Nov 21 '05 #39
"Jay B. Harlow [MVP - Outlook]" <Ja************@msn.com> schrieb:
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.

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #40
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
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.


The reason /I/ use 'Int32', ... for interop code is readability. It's not
the fear that sooner or later 'Integer' will change its underlying type.
Using 'Int32' in interop code makes it easier for me to adapt interop code
to 64 bit versions. 'Integer' doesn't need to be checked, but 'Int32' needs
to be checked and adapted, when p/invoking on a 64-bit version of Windows
XP, for example.
Therefore we disagree in this, I think Microsoft did not advice
Integer just for fun.
'Integer', 'Short', ... are less technical than 'Int32', 'Int64', and
consequently it's easier to distinguish between the aliases.
But future will tell, now it is academic


:-)

--
Herfried K. Wagner [MVP]
<URL:http://dotnet.mvps.org/>
Nov 21 '05 #41
Gerald,
I don't see where the confusion is:

Integer is an alias for System.Int32 on the current 32-bit version of the
framework.

Integer is an alias for System.Int32 on the current 64-bit version of the
Framework, currently in Beta.

For details on the 64-bit Framework see:

http://msdn.microsoft.com/msdntv/epi...B/manifest.xml
I use the explicit types for unmanged code more because the size of the
unmanaged code types may change, not that the size of the managed code types
may change, the managed code types aren't changing...

So my API may be:

' 32-bit API needs a 32 bit count:
Declare Auto Sub WonderBarAPI Lib "WonderBar" (ByVal ptr As IntPtr,
ByVal count As System.Int32)

' 64-bit API needs a 64 bit count
Declare Auto Sub WonderBarAPI Lib "WonderBar" (ByVal ptr As IntPtr,
ByVal count As System.Int64)

Looking at the above I would probably define count as IntPtr also, then I
don't need to worry about the size disparity.

Hope this helps
Jay

"Gerald Hernandez" <Cablewizard@sp*********@Yahoo.com> wrote in message
news:%2****************@TK2MSFTNGP14.phx.gbl...
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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:eT**************@tk2msftngp13.phx.gbl...
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

"John Baker" <wb********@wzwfreivprf.pbz>
> 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?
> --
> To Email Me, ROT13 My Shown Email Address
>



Nov 21 '05 #42
Hello Gerald,

I know that you can easily extend the type system in C# and VB by declaring your own types, but you are talking here about primitive types and I'm not sure you can alias language keywords. While the choice of datatype is not explicitly defined by the processor, it can be defined by the language itself if the developer is not careful in choosing their type. You can easily extend the primitive types, but I don't think you can replace them.

Thanks,
Matt Ranlett
mailto:mr******@devcowsoftware.com
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uz**************@TK2MSFTNGP09.phx.gbl...
"Larry Serflaten" <se*******@usinternet.com> schrieb:
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 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

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


Nov 21 '05 #43
Cor,
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. 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.
But future will tell, now it is academic 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" <no************@planet.nl> wrote in message
news:eD*************@TK2MSFTNGP11.phx.gbl... 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

Nov 21 '05 #44
heh, i'm not actually proposing that such a define would work at the user
code level, but at the compiler level. given that Integer is currently an
alias for Int32 now. this was only intended to be pseudo-code representation
of a platform dependant alias might look like.

Gerald

"Matt Ranlett" <mr******@devcowsoftware.com> wrote in message
news:X6*****************@bignews5.bellsouth.net...
Hello Gerald,

I know that you can easily extend the type system in C# and VB by declaring your own types, but you are talking here about primitive types and
I'm not sure you can alias language keywords. While the choice of datatype
is not explicitly defined by the processor, it can be defined by the
language itself if the developer is not careful in choosing their type. You
can easily extend the primitive types, but I don't think you can replace
them.
Thanks,
Matt Ranlett
mailto:mr******@devcowsoftware.com
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

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uz**************@TK2MSFTNGP09.phx.gbl...
"Larry Serflaten" <se*******@usinternet.com> schrieb:

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

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

Nov 21 '05 #45
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]" <Ja************@msn.com> wrote in message
news:eH**************@TK2MSFTNGP09.phx.gbl...
Cor,
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.

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.
But future will tell, now it is academic

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" <no************@planet.nl> wrote in message
news:eD*************@TK2MSFTNGP11.phx.gbl...
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


Nov 21 '05 #46
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.

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.


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
Nov 21 '05 #47
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
Nov 21 '05 #48
Cor,

"Cor Ligthert" <no************@planet.nl> schrieb:
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.
That's a valid point! I must admit that there is no guarantee that
everything I say is right.
I can assure you I would save that statement when it was a guy from
Microsoft who told that.
:-)

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.
However in my mind I am sure those regular MVP's from this
newsgroup will support me when it is serious.

:-)


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/>
Nov 21 '05 #49

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP15.phx.gbl...
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

Nov 21 '05 #50

This discussion thread is closed

Replies have been disabled for this discussion.

By using this site, you agree to our Privacy Policy and Terms of Use.