VB Conversion Keywords And .NET Conversion Routines

[Cor Ligthert]

In fact all three (CInt, Math.Round, Convert.ToInt16) do banker's rounding

as .NET does banker's rounding.

Where I have understand from the documentation there would be more
posibilities in 2.0

 

[Cor Ligthert]

Bob,

There is in all program and natural languages a lot of legacy. To keep it
with the program languages how older the language the more legacy. There is
in my opinion a lot of legacy in all from C derived program languages.

To say something about your point of view; because of the fact that
Microsoft.VisualBasic is an integrated part from the framework, can you not
skip methods from that.

To give an analogy
You can say that the USA is America and in the same way that the EU is
Europe.

However, because of that is Brazil not a legacy part of America and Russia a
legacy part of Europe.

Just my thought,

Cor

 

[Jay B. Harlow [MVP - Outlook]]

Dennis
False speculation:

In VB.NET 2005 (.net 2.0) aka Whidbey due out later in 2005. Integer remains
an alias for Int32 on both the 32-bit & 64-bit versions of the runtime.
There has been long discussions on this with numerous links. If you want the
links I can look for them.

Seeing as .NET 2.0 has a 64-bit framework & didn't change why would it
change in VB.NET 2007 (.net 3.0+)?

Hope this helps
Jay

What if in vb.Net 2007 an integer becomes 8 bytes and a double becomes 16
bytes, would not then Cint and Cdbl or Ctype maintain more consistency of
code and automatically utilize 8 byte integers as opposed to
Convert.ToInt32?
In the 64bit world, this could become real confusing. Wonder how M'soft
will handle it?

rawCoder,

May b someone from Visual Basic Development team might be in the best
position to tell us ...

In case you missed it:

www.panopticoncentral.net is Paul Vick's blog, Paul Vick is the Technical
Lead of the Visual Basic.NET Development team at Microsoft, here is his
thoughts:

http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx


Hope this helps
Jay

Thank you all for your comments.

Seems like the comments are a little diverse than i expected them to be
which might mean that the problem isnt that simple as it initially
seemed
to
me. I hope I aint asking for too much but can someone please summarize
(
if
possible ) the differences in terms of performance and IL generation
for
the
followings.

Intrinsic VB Conversion Ops ( CInt, CBool, CDbl, CLng, CObj, CStr
etc. )
Convert class Convert.To methods
CType method
DirectCast method

I understand that there are differences of ValueType and ReferenceType
and
the datatype diffreneces also count, but there must be some flow or
checklist to identify excatly when should one use which conversion
technique..

May b someone from Visual Basic Development team might be in the best
position to tell us which IL is better

( Dim i As Integer = CInt("1") )
IL_0001: ldstr "1"
IL_0006: call int32
[Microsoft.VisualBasic]Microsoft.VisualBasic.CompilerServices.IntegerType::F
romString(string)
IL_000b: stloc.0

( Dim j As Integer = CInt("2") )
IL_000c: ldstr "2"
IL_0011: call int32 [mscorlib]System.Convert::ToInt32(string)
IL_0016: stloc.1

Thank You Again All.
rawCoder

 

[Cor Ligthert]

Dennis,

I thought that there are still discussions if an Intel 64Bits will be one
32Bits processor or a 2 times 32Bits processor.

A proffesional program language builder would never decide to set his
standard calculating/indexer format to another format than the most optimal
for the most used processor.

That would direct be an (easy) advantage for all is concurents when he did
not and they did.

Although I feel something for the argument from Jon (and than of course an
upgrade procedure from Integer to let say PF. (Processor Format).

It seems that Microsoft has told with the last upgrade from 16Bits Basic to
32Bits VB that they would never do that anymore. However I think that a
VBNet programmer is not a Basic 2 programmer.

Just my thought,

Cor