VB Conversion Keywords And .NET Conversion Routines

[rawCoder]

Hi,

Just wanted to know if there is any speed difference between

VB conversion Keywords like CInt, Clng, CStr, CDbl, CBool etc.
..NETs Convert.To<...> methods.

And which is better to be used and why ?

Thanx
rawCoder

 

[Bob Grommes]

Personally I use the generic .NET methods like Convert.ToInt32() instead of
CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#. Some of the VB legacy conversion methods have
backward compatibility baggage. I don't recall the specifics, but it's best
to make direct calls into the CLR so you know exactly what you're getting,
when writing new code. When converting legacy VB6 code, that's when you'd
use the VB versions, at least in early iterations of the conversion.

The best you can hope for, it seems to me, is that CInt() does nothing more
than call Convert.ToInt32(); at minimum, that's an extra call. I'd just as
soon avoid that.

Another oft-overlooked issue is that when writing new code it's better to
use AndAlso / OrElse rather than And/Or, so that you get rid of one of VB's
most annoying features: lack of short-circuit evaluation. Again, you'd
stick with And / Or when trying to get a clean conversion of legacy VB6
code, or on those rare occasions when you actually don't want short-circuit
evaluation.

--Bob

 

[Cor Ligthert]

Bob,

Personally I use the generic .NET methods like Convert.ToInt32() instead
of CInt(), etc. This makes your programs more congruent with other .NET
languages, including C#.

What is the advantage from this, in my idea can you than better write it
direct in C

Some of the VB legacy conversion methods have backward compatibility
baggage.

What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java and
what ever from C derived languages have a lot of legacy C stuff. (With what
in my opinion is almost nothing wrong by the way)

Cor

 

[Bob Grommes]

Bob,


What is the advantage from this, in my idea can you than better write it
direct in C

All I'm saying is that the CLR provides virtually all the classes and
methods you need for conversions. .NET-hosted languages that have legacy
syntax for doing the same things as the CLR methods will either implement
compiler syntax sugar that substitutes CLR calls for the legacy syntax, or
they will provide a library that implements the legacy syntax / behaviors.
VB.NET does primarily the latter, but with a little bit of syntax sugar --
the namespace / library where the compatibility methods exist is always
automatically referenced without the VB.NET developer having to do anything.

In the best case, if you call the legacy VB function CInt(), it's just going
to forward it to Convert.ToInt32() anyway. Why not avoid that extra call?
In the worst case, CInt() is going to implement some legacy behavior that
might be even more expensive. For example it might take Nothing as zero,
which would involve another test or perhaps a try/catch. I don't recall
offhand -- but I remember finding that some of the legacy conversion
functions do jump through extra hoops to behave exactly like legacy VB.

I'm not passing judgment on this as good, bad or indifferent -- it's just
the way it is. I'm sure that some future version of C# will have similar
issues. The initial release of C# didn't have to cope with legacy issues
since it was a brand-new language, but over time, it will. I also assume
that COBOL.NET, S#, Eiffel.NET, etc., have similar kludges to help legacy
code run somewhat as-is.

What are VB legacy conversion methods. C#, C++, J++, JavaScript and Java
and what ever from C derived languages have a lot of legacy C stuff. (With
what in my opinion is almost nothing wrong by the way)

I'm not referring to language characteristics or conventions that descend
from predecessor languages. I'm referring to keywords / functions /
commands that are obsoleted by the provided .NET classes and which exist
only so that code written for previous, non .NET versions of those languages
will come as close as feasible to running unchanged.

I don't think anyone seriously recommends using, for example, PRINT#
statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.
People use them to ease the incorporation of legacy code into .NET apps, or
out of habit; I'm simply advocating that they be treated like deprecated
HTML tags, which is to say, they will probably not be supported someday and
there are arguably better ways of doing the same things.

The parallel to deprecated HTML tags also cuts the other way. <B> is
deprecated, for example, but so many people continue to use it that it
probably will continue to be supported just from sheer inertia. That
probably means it's simple and abbreviated enough that it is useful and
appealing despite the fact it's obsolete. One could argue that CInt() is
more concise than Convert.ToInt32() and maybe on that basis plus the fact
that probably most VB.NET developers started out with VB6, CInt() will
remain enshrined in the language forever. Personally though I prefer to
take the larger view that you want VB.NET to participate as an equal partner
with other .NET languages and it should play in the sandbox the same way so
that programmers can move between VB.NET and other .NET languages with a
minimum of quirky exceptions to how things are done from one language to the
next.

--Bob

 

[Jay B. Harlow [MVP - Outlook]]

Bob,

The initial release of C# didn't have to cope with legacy issues since it
was a brand-new language,

What do you consider "(int)" in C#?

I hope you realize that "(int)" in C# is the same as CInt in a number of
cases.

The "nice" thing about CInt is it is more powerful, then either "(int)" or
Convert.ToInt32, as it combines both, plus.

I don't think anyone seriously recommends using, for example, PRINT#

The PRINT# keyword is not even available in VB.NET, so why would any one
even consider recommending it?

The Print# keyword has been replaced with the
Microsoft.VisualBasic.FileSystem.Print function in the VB.NET runtime. The
VB.NET runtime is an integral part of the VB.NET language.

statements in VB.NET. They're obsolete. CInt() / CDbl(), etc., are, too.

CInt & CDbl are no where near obsolete, they are keywords which are an
integral part of the VB.NET language, just as are If, Sub, Property, and
every other keyword in VB.NET. Not to be confused with VB6 keywords that are
retained in VB.NET and not actually used, such as GOSUB.

If you have not yet read Paul Vick's article on CInt & such, I strongly
suggest you do:

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

Unfortunately I don't have access to my VS.NET 2005 partition right now, I
understand that CInt, CDbl, etc have expanded usage in VB.NET 2005! In that
they honor overloaded operators:

http://www.panopticoncentral.net/archive/2004/07/01/1338.aspx
http://msdn.microsoft.com/vbasic/wh...y/en-us/dnvs05/html/vboperatoroverloading.asp

Hope this helps
Jay

 

[Guest]

Don't you think that the compiler compiles Cint function to basically the
same as Convert.ToInteger32? I really wonder if Cint function calls
convert.ToInteger32. Are you positive about this?

 

[Bob Grommes]

Dennis,

I am accustomed to using the static Convert methods in C# and my most
extensive legacy VB experience was with ASP/VBScript, where I found the
various intrinsic conversion functions rather overly "helpful" and sometimes
just plain strange (e.g., banker's rounding). Moving back and forth between
VB.NET and C#, I find that consistency and predictabiliy to be something I
value. Your mileage, and your priorities, may vary.

Regarding CInt() specifically, one of the links provided by another posted
in this thread concedes that for example CInt(string) is "slightly" slower
than Convert.ToInt32(string) but that CInt(long) would be faster than
Convert.ToInt32(long) because CInt(long) compiles directly to a single IL
instruction. So it looks like performance differences vary in both
directions and perhaps it is just down to a combination of personal
preference and habit after all.

--Bob

 

[Scott M.]

Where do CType and DirectCast fit into this? I know that DirectCast is more
efficient than CType when it can be used, but isn't the single use of CType
easier and more consistent than the various CInt, Cstr, CBool, CDbl, etc.
functions?

 

[Guest]

Where do CType and DirectCast fit into this? I know that DirectCast is more
efficient than CType when it can be used, but isn't the single use of CType
easier and more consistent than the various CInt, Cstr, CBool, CDbl, etc.
functions?

***
Why?
CInt is more readable and requires less typing (always a plus for me!) than
CType
and remember, the less you type the less bugs you get
***

 

[Cor Ligthert]

Scott,

In other words

The DirectCast "Take as"
The CType "Convert to"

Cor

 

[Cor Ligthert]

Bob,

Regarding CInt() specifically, one of the links provided by another posted
in this thread concedes that for example CInt(string) is "slightly" slower
than Convert.ToInt32(string)

What is not true I tested it yesterday (I deleted the test already) and the
figurs where 2:1 however that in a processing time which does in my opinion
in a normal 80:20 optimizing situation not has the influence real to think
about.

Cor

 

[Herfried K. Wagner [MVP]]

Where do CType and DirectCast fit into this? I know that DirectCast is
more efficient than CType when it can be used

For reference types the compiler will create the exact same IL for both,
'CType' and 'DirectCast', so the performance is equal. I prefer
'DirectCast' in this case to make it more obvoius that only a type cast is
going on and not a type conversion.

but isn't the single use of CType easier and more consistent than the
various CInt, Cstr, CBool, CDbl, etc. functions?

'CType(Foo, Integer)' compiles to the same IL as 'CInt(...)' does. I think
that 'CInt', 'CStr', etc. are far better readable than 'CType(..., ...)'.

 

[rawCoder]

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

 

[Daniel Moth]

If you know the datatype matches your target then you are after a cast so
use DirectCast. Nobody will disagree with that (famous last words

If you want to do a conversion then you have two choices:
1. Convert.ToXXX
or
2. the VB conversions (whether you go with CInt, CBool etc or with CType is
down to coding preference, end of story)

The performance difference between the two does not justify using one over
the other so it comes down to preference again. The advice is to stop
looking at it as a performance thing and choose based on your team's coding
standards (consistency is more important).

My *personal* preference is always 1. It makes converting code from one
language to the other easier and since I work in both languages it makes
reading code easier too. Your requirements may vary.

Cheers
Daniel

 

[Cor Ligthert]

RawCoder,

You will by the team than probably be directed too this page

http://msdn.microsoft.com/library/d...tml/vbtchmicrosoftvisualbasicnetinternals.asp

In the section
Conversion Functions, CType, DirectCast, and System.Convert
Maybe you can read it allready before



Cor

 

[Scott M.]

Well, I don't necessarily agree, in that with CType, there is just one
function to use. Rather than the 5 or 6 legacy conversion functions. I
find CType to be more consistent.

 

[Scott M.]

That doesn't really address my question Cor. My question was what (if any)
advantage is there to using CInt or Convert.ToInt16 over CType or
DirectCast?

 

[Jay B. Harlow [MVP - Outlook]]

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

 

[=?ISO-8859-1?Q?=22D=2E_Andr=E9_Dhondt=22?=]

That doesn't really address my question Cor. My question was what (if any)
advantage is there to using CInt or Convert.ToInt16 over CType or
DirectCast?

Set up a loop to do these conversions 10,000 times and test each method
5 or so times (cause a timed loop could be affected by background
processes as well)--please share the results with the group.

 

[Cor Ligthert]

Scott,

Probably I misunderstood you.
For me is using CInt just that it are 4 letters to type instead of
CType(xx,xx) in the cases where I can use it

For the rest see this page which I sent today as answer to RawCoder as well.

http://msdn.microsoft.com/library/d...tml/vbtchmicrosoftvisualbasicnetinternals.asp

In the section
Conversion Functions, CType, DirectCast, and System.Convert

I hope that it clears it a little bit more.

Cor