ANN: Future of .NET

[Jon Skeet [C# MVP]]

In VB6, which is VB.NET's predecessor according to Microsoft, 'Integer' has
been specified as 16-bit number. Nevertheless the name 'Integer' is mapped
to a 32-bit type in VB.NET. Thus I would not put my money on 'Integer'
referring to the same 32-bit type in .NEW (.NET's successor which may
include "new versions" of VB and C#).

Well, that would no longer be VB.NET. I think it's entirely reasonable
to depend on Integer not changing in VB.NET or C# themselves.

Out of interest, is there a VB6 language specification available online
anywhere?

 

[Herfried K. Wagner [MVP]]

Jon,

Out of interest, is there a VB6 language specification available online
anywhere?

It's not called "specification", but you'll find the "reference" here:

<URL:http://msdn.microsoft.com/library/en-us/VBRef98/html/vbmscLROverview.asp>

 

[Rob Nicholson]

No, it can't grow on either C# or VB.NET. It's precisely specified in

both languages.

So what's the 64 bit incarnation going to be called?

Cheers, Rob.

 

[Rob Nicholson]

Are you sure you read my post?

Nope, not all of it

 

[Herfried K. Wagner [MVP]]

So what's the 64 bit incarnation going to be called?

'Long' (= 'Int64').

 

[Jon Skeet [C# MVP]]

So what's the 64 bit incarnation going to be called?

Int64 in CLR terms, long in C#, and Long in VB.NET.

If they decide to introduce a 128-bit integer type, then either they'll
need to introduce a new keyword (please let us *not* have "long long"!)
or leave it as a type which doesn't have a shorthand in the language.

 

[Rob Nicholson]

So what's the 64 bit incarnation going to be called?

'Long' (= 'Int64').

And when we get to 128 bit

Rob.

 

[Rob Nicholson]

If they decide to introduce a 128-bit integer type, then either they'll

need to introduce a new keyword (please let us *not* have "long long"!)
or leave it as a type which doesn't have a shorthand in the language.

Ohh what a complex debate I bet they have in the language departments

Rob.

 

[Phill. W]

It's 7.1.

VS.NET 2002: 7.0
VS.NET 2003: 7.1
VS 2005: 8.0

OK, time for a silly question - it must be my turn again, by now

Given that VS'2003 is version "7.1", why does /this/ appear in all
my '2003 solution files?

"Microsoft Visual Studio Solution File, Format Version 8.00"

And what will appear in 'Studio 2005's Solutions?
(Since I have an automated build server wherein I use the above to
determine the correct version of 'Studio with which to compile said
solution, this is /not/ as trivial a question as it might at first appear
....

TIA,
Phill W.

 

[Søren Reinke]

If they decide to introduce a 128-bit integer type, then either they'll
need to introduce a new keyword (please let us *not* have "long long"!)

Don't worry i think it will be like this:

32bit Int
64bit Long
128bit Verylong
256bit ExtremlyLong
512bit IncredibleLong
1024bit Tolong

 

[Herfried K. Wagner [MVP]]

OK, time for a silly question - it must be my turn again, by now

Given that VS'2003 is version "7.1", why does /this/ appear in all
my '2003 solution files?

"Microsoft Visual Studio Solution File, Format Version 8.00

That's simply a file format version which is not the same as the IDE
version.

And what will appear in 'Studio 2005's Solutions?

9.0.

 

[Larry Lard]

OK, time for a silly question - it must be my turn again, by now

Given that VS'2003 is version "7.1"

Bzzzt, not quite The version *of VB* that you find in VS 2003 is
*VB* version 7.1.

, why does /this/ appear in all

my '2003 solution files?

"Microsoft Visual Studio Solution File, Format Version 8.00"

Because whoever coded that file format decided VS 2003 is version 8 *of
Visual Studio* (which makes sense, since it's two versions after VS6
(the last one explicitly named by version, I think)), so its Solution
Files are version 8 solution files. Now, this was probably an unwise
choice, but it's released now, so we're all stuck with it...

And what will appear in 'Studio 2005's Solutions?

Someone with the VS2005 beta will be able to tell you what the beta
calls them... who knows what the releasd version will call them!

(Since I have an automated build server wherein I use the above to
determine the correct version of 'Studio with which to compile said
solution, this is /not/ as trivial a question as it might at first appear

Not trivial at all.

 

[Jon Skeet [C# MVP]]

Ohh what a complex debate I bet they have in the language departments

Well, introducing a new keyword is a *huge* step for a language -
especially one which needs to be exposed in a place like variable
declarations.

My personal bet is that they just won't add a shorthand for it - I
don't think it'll be used as often as int and long anyway, so there's
less benefit.

 

[Rob Nicholson]

My personal bet is that they just won't add a shorthand for it - I

don't think it'll be used as often as int and long anyway, so there's
less benefit.

So we'll all continue using Integer so produce code that doesn't naturally
optimise for a 64 bit environment. As I said elsewhere, a decision that has
pros and cons.

Cheers, Rob.

 

[Rob Nicholson]

32bit Int

64bit Long
128bit Verylong
256bit ExtremlyLong
512bit IncredibleLong
1024bit Tolong

How about this though - you include some declaration in your program that
Integer must be at least 32 bit and can either a) be expanded up to 64 bit
(or higher) without impact or b) must stay as 32 bit and therefore not be
optimised to the CPU's natural integer size.

If run on a 16 bit machine, then it's going to have to split the
variable/math into 16 bit chunks and do multiple math (nothing new there).

If run on a 64 bit or higher machine in case (a) the integers grow to 64 bit
or higher and run as native integers. If run on a 64 bit or higher machine
in case (b) then less than native size integers are used, possibly
introducting a performance hit.

Cheers, Rob.

 

[Jon Skeet [C# MVP]]

So we'll all continue using Integer so produce code that doesn't naturally
optimise for a 64 bit environment. As I said elsewhere, a decision that has
pros and cons.

I think you missed the part which said that I didn't think a 128 bit
type would get its own keyword. Long's already there.

 

[Jon Skeet [C# MVP]]

How about this though - you include some declaration in your program that
Integer must be at least 32 bit and can either a) be expanded up to 64 bit
(or higher) without impact or b) must stay as 32 bit and therefore not be
optimised to the CPU's natural integer size.

Please no. We've been there with C/C++ - the result is a mess.

If you really need a type whose size is the natural size of an integer
on your box, use IntPtr.

(I haven't seen any evidence suggesting that using 32 bit integers on a
64 bit box introduces any performance problems, btw.)

 

[Rob Nicholson]

Please no. We've been there with C/C++ - the result is a mess.

Not quiet - you couldn't add metadata to your problem to indicate the size
of integer assumed which is where the problems occur.

Cheers, Rob.

 

[Jon Skeet [C# MVP]]

Not quiet - you couldn't add metadata to your problem to indicate the size
of integer assumed which is where the problems occur.

And everyone would do that, I suppose? No, it sounds like a very, very
bad idea which is very easily avoided by just not changing the
specification.

 

[Cor Ligthert [MVP]]

Hi,

In my opinion should there be a value type that references to the standard
register format. As Integer has been in VBNet and because it was the first
time in C# for int.

Long has a to long history to be in my opinion useable for that.

Cor