469,353 Members | 2,060 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

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

VB Conversion Keywords And .NET Conversion Routines

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


Nov 21 '05 #1
47 2430
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

"rawCoder" <ra******@hotmail.com> wrote in message
news:eh*************@TK2MSFTNGP15.phx.gbl...
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

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

"rawCoder" <ra******@hotmail.com> wrote in message
news:eh*************@TK2MSFTNGP15.phx.gbl...
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

Nov 21 '05 #3
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
Nov 21 '05 #4
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
Nov 21 '05 #5
"Cor Ligthert" <no************@planet.nl> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
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


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


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
Nov 21 '05 #7
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/arc...6/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/arc...7/01/1338.aspx
http://msdn.microsoft.com/vbasic/whi...verloading.asp

Hope this helps
Jay

"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:e3**************@TK2MSFTNGP09.phx.gbl... "Cor Ligthert" <no************@planet.nl> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
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


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

Nov 21 '05 #8
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/arc...6/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/arc...7/01/1338.aspx
http://msdn.microsoft.com/vbasic/whi...verloading.asp

Hope this helps
Jay

"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:e3**************@TK2MSFTNGP09.phx.gbl... "Cor Ligthert" <no************@planet.nl> wrote in message
news:uQ**************@TK2MSFTNGP09.phx.gbl...
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


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

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


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

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

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:99**********************************@microsof t.com...
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?

Nov 21 '05 #11
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?
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:OQ**************@TK2MSFTNGP12.phx.gbl...
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

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:99**********************************@microsof t.com...
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?


Nov 21 '05 #12
guy


"Scott M." wrote:
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
***
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:OQ**************@TK2MSFTNGP12.phx.gbl...
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

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:99**********************************@microsof t.com...
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?



Nov 21 '05 #13
Scott,

In other words

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

Cor
Nov 21 '05 #14
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
Nov 21 '05 #15
"Scott M." <s-***@nospam.nospam> schrieb:
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(..., ...)'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #16
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
Nov 21 '05 #17
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
--
http://www.danielmoth.com/Blog/
"rawCoder" <ra******@hotmail.com> wrote in message
news:uE**************@TK2MSFTNGP14.phx.gbl...
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


Nov 21 '05 #18
RawCoder,

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

http://msdn.microsoft.com/library/de...tinternals.asp

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

:-)

Cor
Nov 21 '05 #19
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.
"guy" <gu*@discussions.microsoft.com> wrote in message
news:B4**********************************@microsof t.com...


"Scott M." wrote:
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
***


"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:OQ**************@TK2MSFTNGP12.phx.gbl...
> 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
>
> "Dennis" <De****@discussions.microsoft.com> wrote in message
> news:99**********************************@microsof t.com...
>> 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?
>
>


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

"Cor Ligthert" <no************@planet.nl> wrote in message
news:u%******************@TK2MSFTNGP09.phx.gbl...
Scott,

In other words

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

Cor

Nov 21 '05 #21
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/arc...6/07/1200.aspx
Hope this helps
Jay
"rawCoder" <ra******@hotmail.com> wrote in message
news:uE**************@TK2MSFTNGP14.phx.gbl... 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

Nov 21 '05 #22
Scott M. wrote:
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?

"Cor Ligthert" <no************@planet.nl> wrote in message
news:u%******************@TK2MSFTNGP09.phx.gbl...
Scott,

In other words

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

Cor


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

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

I hope that it clears it a little bit more.

Cor
Nov 21 '05 #24
Scott,
Paul's blog indicates that CInt() is an alias for CType(, Integer).

As Cor suggests CType is the conversion operator, while DirectCast is the
cast operator.

To "confuse" the issue the Conversion operator can be used as the cast
operator, however I make every effort to avoid this, as VS.NET 2005 allows
operator overloading! With operator overloading we can use the Conversion
operator (CType) to convert our types as needed.

http://msdn2.microsoft.com/library/yf7b9sy7.aspx
For example we can define the conversion for a Rational (Fraction) type to &
from Double. Where the Rational type holds the Numerator & Denominator as
separate fields. CType will be able to use the overloaded conversion
operators, while I understand that Convert.To* will not.

Public Structure Rational

Private m_numerator As Integer
Private m_denominator As Integer

Public Shared Widening Operator CType(ByVal f As Rational) As Double
Return f.m_numerator / f.denominator
End Operator

Public Shared Narrowing Operator CType(ByVal d As Double) As Rational
Return New Rational(d)
End Operator

End Structure
Dim f As Fraction
Dim d As Double

f = CType(d, Fraction)
d = f

Hope this helps
Jay

"Scott M." <s-***@nospam.nospam> wrote in message
news:%2****************@TK2MSFTNGP12.phx.gbl...
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?

"Cor Ligthert" <no************@planet.nl> wrote in message
news:u%******************@TK2MSFTNGP09.phx.gbl...
Scott,

In other words

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

Cor


Nov 21 '05 #25
I'm given to understand that CType() itself is in fact equivalent to the
corresponding Convert methods, and that DirectCast is about the same as a C#
cast, which is faster since it's a cast rather than a conversion.

In reality I'm not sure that we're doing anything but splitting hairs here
though ... this conversation is interesting but ultimately, in real world
line of business scenarios, the differences in performance are not that
significant. If we were doing matrix math or image manipulation, it might
matter. But if we're simply unboxing datarow values and converting textbox
strings to integer or decimal, and other *typical* operations, it probably
doesn't in fact matter how you accomplish it, from a performance
perspective. So I go for consistency and use metaphors that would be
familiar to any developer who knows the .NET framework, regardless of their
language experience.

--Bob

"Scott M." <s-***@nospam.nospam> wrote in message
news:e8***************@TK2MSFTNGP15.phx.gbl...
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.

Nov 21 '05 #26
Whoops, that was misinformation, I misread an article -- CType() is exactly
equivalent to the corresponding intrinsic VB functions (CInt, etc) not to
Convert methods.

"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
I'm given to understand that CType() itself is in fact equivalent to the
corresponding Convert methods, and that DirectCast is about the same as a
C# cast, which is faster since it's a cast rather than a conversion.

In reality I'm not sure that we're doing anything but splitting hairs here
though ... this conversation is interesting but ultimately, in real world
line of business scenarios, the differences in performance are not that
significant. If we were doing matrix math or image manipulation, it might
matter. But if we're simply unboxing datarow values and converting
textbox strings to integer or decimal, and other *typical* operations, it
probably doesn't in fact matter how you accomplish it, from a performance
perspective. So I go for consistency and use metaphors that would be
familiar to any developer who knows the .NET framework, regardless of
their language experience.

--Bob

"Scott M." <s-***@nospam.nospam> wrote in message
news:e8***************@TK2MSFTNGP15.phx.gbl...
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.


Nov 21 '05 #27
So what then is the difference between CType and the Convert methods?

"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...
Whoops, that was misinformation, I misread an article -- CType() is
exactly equivalent to the corresponding intrinsic VB functions (CInt, etc)
not to Convert methods.

"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
I'm given to understand that CType() itself is in fact equivalent to the
corresponding Convert methods, and that DirectCast is about the same as a
C# cast, which is faster since it's a cast rather than a conversion.

In reality I'm not sure that we're doing anything but splitting hairs
here though ... this conversation is interesting but ultimately, in real
world line of business scenarios, the differences in performance are not
that significant. If we were doing matrix math or image manipulation, it
might matter. But if we're simply unboxing datarow values and converting
textbox strings to integer or decimal, and other *typical* operations, it
probably doesn't in fact matter how you accomplish it, from a performance
perspective. So I go for consistency and use metaphors that would be
familiar to any developer who knows the .NET framework, regardless of
their language experience.

--Bob

"Scott M." <s-***@nospam.nospam> wrote in message
news:e8***************@TK2MSFTNGP15.phx.gbl...
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.



Nov 21 '05 #28
"Scott M." <s-***@nospam.nospam> schrieb:
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.


Why do you think the 'C*' conversion functions are "legacy functions"? They
are part of the Visual Basic language like 'If...Then'. There is
*absolutely no* reason for not using them. Or would you try to avoid to use
'(int)x' in C# because it's "legacy"?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #29
Well, I thought that I did explain why I prefer not to use them. I prefer
the consistency of CType, rather than the various C* functions. In my mind,
the many C* functions have been replaced by just one function to deal with.
In that sense, I can't imagine why anyone would want to use the various C*
functions.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"Scott M." <s-***@nospam.nospam> schrieb:
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.


Why do you think the 'C*' conversion functions are "legacy functions"?
They are part of the Visual Basic language like 'If...Then'. There is
*absolutely no* reason for not using them. Or would you try to avoid to
use '(int)x' in C# because it's "legacy"?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #30
"Legacy" is a matter of perspective. The C*() functions are not legacy VB
functions in the sense that they have been deprecated in the VB language,
but if you take a larger view from a .NET perspective, they are legacy
functions in that they duplicate .NET framework functionality for the sake
of backward compatibility support of a non .NET language. The C*()
functions have no reason to exist other than that, and in that sense they
make VB.NET needlessly different with a divergent syntax and in some cases,
different behaviors or responses to boundary conditions.

If you are developing in other .NET languages as well as VB.NET, the C*()
functions seem much more superfluous than if you come from a VB6 background
and are mostly focused on developing in VB.NET.

Mind you, I'm not asking you to agree or disagree, just to understand that
there are other points of view, and they have validity depending on your
perspective and approach.

--Bob

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"Scott M." <s-***@nospam.nospam> schrieb:
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.


Why do you think the 'C*' conversion functions are "legacy functions"?
They are part of the Visual Basic language like 'If...Then'. There is
*absolutely no* reason for not using them. Or would you try to avoid to
use '(int)x' in C# because it's "legacy"?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #31
"Scott M." <s-***@nospam.nospam> wrote in message
news:OQ**************@TK2MSFTNGP09.phx.gbl...
So what then is the difference between CType and the Convert methods?
The URLs that have been provided elsewhere in this thread explain it better
than I can, but basically, the Convert methods are the way the framework
expects conversions to happen. For example, Convert.ToInt32("2.5") is an
error, whereas CInt("2.5") or CType("2.5",Integer) is not. Furthermore,
CInt("2.5") yields 2 (banker's rounding) whereas Math.Round(2.5,0) yields 3.
I'm sure there are other examples. Personally I don't want to have to
remember special rules for a particular language.

On the plus side, some kinds of calls to the C*() functions are optimized to
be very fast, faster than Convert methods. Such as CInt(someLongValue) or
CLng(someIntValue). But in practice, how often do you actually do such
conversions? In my work, almost never. In any case the consensus in this
thread, with which I now agree, is that real world performance differences
are negligible. So it's probably more important to do what you want, and do
it consistently.

--Bob
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...
Whoops, that was misinformation, I misread an article -- CType() is
exactly equivalent to the corresponding intrinsic VB functions (CInt,
etc) not to Convert methods.

Nov 21 '05 #32
I know you didn't ask for agreement or disagreement, but I wholeheartedly
agree and think that you couldn't have summed it up better Bob.
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:O5**************@tk2msftngp13.phx.gbl...
"Legacy" is a matter of perspective. The C*() functions are not legacy VB
functions in the sense that they have been deprecated in the VB language,
but if you take a larger view from a .NET perspective, they are legacy
functions in that they duplicate .NET framework functionality for the sake
of backward compatibility support of a non .NET language. The C*()
functions have no reason to exist other than that, and in that sense they
make VB.NET needlessly different with a divergent syntax and in some
cases, different behaviors or responses to boundary conditions.

If you are developing in other .NET languages as well as VB.NET, the C*()
functions seem much more superfluous than if you come from a VB6
background and are mostly focused on developing in VB.NET.

Mind you, I'm not asking you to agree or disagree, just to understand that
there are other points of view, and they have validity depending on your
perspective and approach.

--Bob

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:%2****************@tk2msftngp13.phx.gbl...
"Scott M." <s-***@nospam.nospam> schrieb:
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.


Why do you think the 'C*' conversion functions are "legacy functions"?
They are part of the Visual Basic language like 'If...Then'. There is
*absolutely no* reason for not using them. Or would you try to avoid to
use '(int)x' in C# because it's "legacy"?!

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>


Nov 21 '05 #33
Bob,
Furthermore, CInt("2.5") yields 2 (banker's rounding) whereas
Math.Round(2.5,0) yields 3. They both yield 2 in both VS.NET 2002 & VS.NET 2003 (.NET 1.0 SP3 & .NET 1.1
SP1). I would be very surprised if this changed in VS.NET 2005, I do however
understand that VS.NET 2005 gives us the option to use Banker's Rounding or
not.

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

Try the following:
Debug.WriteLine(CInt(2.5), "CInt(2.5) ")
Debug.WriteLine(CInt("2.5"), "CInt(""2.5"")")
Debug.WriteLine(Convert.ToInt32(2.5), "Convert.ToInt32(2.5)")
Debug.WriteLine(Math.Round(2.5, 0), "Round(2.5)")
Debug.WriteLine(CInt(1.5), "CInt(1.5) ")
Debug.WriteLine(CInt("1.5"), "CInt(""1.5"")")
Debug.WriteLine(Convert.ToInt32(1.5), "Convert.ToInt32(1.5)")
Debug.WriteLine(Math.Round(1.5, 0), "Round(1.5)")

Hope this helps
Jay
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:u4**************@TK2MSFTNGP09.phx.gbl... "Scott M." <s-***@nospam.nospam> wrote in message
news:OQ**************@TK2MSFTNGP09.phx.gbl...
So what then is the difference between CType and the Convert methods?


The URLs that have been provided elsewhere in this thread explain it
better than I can, but basically, the Convert methods are the way the
framework expects conversions to happen. For example,
Convert.ToInt32("2.5") is an error, whereas CInt("2.5") or
CType("2.5",Integer) is not. Furthermore, CInt("2.5") yields 2 (banker's
rounding) whereas Math.Round(2.5,0) yields 3. I'm sure there are other
examples. Personally I don't want to have to remember special rules for a
particular language.

On the plus side, some kinds of calls to the C*() functions are optimized
to be very fast, faster than Convert methods. Such as CInt(someLongValue)
or CLng(someIntValue). But in practice, how often do you actually do such
conversions? In my work, almost never. In any case the consensus in this
thread, with which I now agree, is that real world performance differences
are negligible. So it's probably more important to do what you want, and
do it consistently.

--Bob
"Bob Grommes" <bo*@bobgrommes.com> wrote in message
news:Ov**************@TK2MSFTNGP12.phx.gbl...
Whoops, that was misinformation, I misread an article -- CType() is
exactly equivalent to the corresponding intrinsic VB functions (CInt,
etc) not to Convert methods.


Nov 21 '05 #34
"Scott M." <s-***@nospam.nospam> schrieb:
Well, I thought that I did explain why I prefer not to use them. I prefer
the consistency of CType, rather than the various C* functions.
I prefer the readability of code that uses the various 'C*' functions :-).
In my mind, the many C* functions have been replaced by
just one function to deal with.


The 'C*' functions were not replaced. Instead, 'CType' was added to allow
explicit casting to user defined types when using strict semantics.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #35
Bob,

"Bob Grommes" <bo*@bobgrommes.com> schrieb:
"Legacy" is a matter of perspective. The C*() functions are not legacy VB
functions in the sense that they have been deprecated in the VB language,
but if you take a larger view from a .NET perspective, they are legacy
functions in that they duplicate .NET framework functionality for the sake
of backward compatibility support of a non .NET language.
So '(int)', '(string)' etc. in C# are casts that should not be used because
they are included for backward compatibility reasons too? I feel sorry, but
I cannot follow this argumentation. There are /so many/ features in
VB.NET/C# that wrap around low-level features provided by the .NET
Framework. That does't make them bad features.
The C*() functions have no reason to exist other than that,
and in that sense they make VB.NET needlessly different with
a divergent syntax
Is 'Select Case' a legacy statement too? You could replace it by lots of
'If's. Isn't VB.NET/C# only a replacement for pure and clean MSIL?
If you are developing in other .NET languages as well as VB.NET, the C*()
functions seem much more superfluous than if you come from a VB6
background and are mostly focused on developing in VB.NET.
I am developing in C# too, but that /never/ lead me to think that 'CInt',
etc. are redundant. They are syntax shortcuts like the '+' operator, for
example. The can be used but there are alternatives. Nevertheless, I try
to pick the feature out of the set of semantically equivalent features that
are available by choosing the feature with the best readability and
maintainability. For me, it does not matter how easily code can be
converted to another .NET programming language, because this would reduce
productivity without adding any value.
Mind you, I'm not asking you to agree or disagree, just to understand that
there are other points of view, and they have validity depending on your
perspective and approach.


:-)

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #36
Herifried, I don't think you really read my post. I'm not looking for an
argument. You wrote:
There is *absolutely no* reason for not using them.

and I simply told you why I prefer to not use them.

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:ui**************@TK2MSFTNGP12.phx.gbl... "Scott M." <s-***@nospam.nospam> schrieb:
Well, I thought that I did explain why I prefer not to use them. I
prefer the consistency of CType, rather than the various C* functions.


I prefer the readability of code that uses the various 'C*' functions :-).
In my mind, the many C* functions have been replaced by
just one function to deal with.


The 'C*' functions were not replaced. Instead, 'CType' was added to allow
explicit casting to user defined types when using strict semantics.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #37
Herfried, take a deep breath. I think we are at the point in this thread
where it's pretty clear we are talking about preferences and you are trying
to "argue" your preference over others. If there was only one choice, then
there wouldn't be a need for preferences.

I say tom-A-to, you say to-MA-to.


"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:el*************@tk2msftngp13.phx.gbl...
Bob,

"Bob Grommes" <bo*@bobgrommes.com> schrieb:
"Legacy" is a matter of perspective. The C*() functions are not legacy
VB functions in the sense that they have been deprecated in the VB
language, but if you take a larger view from a .NET perspective, they are
legacy functions in that they duplicate .NET framework functionality for
the sake of backward compatibility support of a non .NET language.


So '(int)', '(string)' etc. in C# are casts that should not be used
because they are included for backward compatibility reasons too? I feel
sorry, but I cannot follow this argumentation. There are /so many/
features in VB.NET/C# that wrap around low-level features provided by the
.NET Framework. That does't make them bad features.
The C*() functions have no reason to exist other than that,
and in that sense they make VB.NET needlessly different with
a divergent syntax


Is 'Select Case' a legacy statement too? You could replace it by lots of
'If's. Isn't VB.NET/C# only a replacement for pure and clean MSIL?
If you are developing in other .NET languages as well as VB.NET, the C*()
functions seem much more superfluous than if you come from a VB6
background and are mostly focused on developing in VB.NET.


I am developing in C# too, but that /never/ lead me to think that 'CInt',
etc. are redundant. They are syntax shortcuts like the '+' operator, for
example. The can be used but there are alternatives. Nevertheless, I try
to pick the feature out of the set of semantically equivalent features
that are available by choosing the feature with the best readability and
maintainability. For me, it does not matter how easily code can be
converted to another .NET programming language, because this would reduce
productivity without adding any value.
Mind you, I'm not asking you to agree or disagree, just to understand
that there are other points of view, and they have validity depending on
your perspective and approach.


:-)

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #38
"Scott M." <s-***@nospam.nospam> schrieb:
Herifried, I don't think you really read my post. I'm not looking for an
argument.


Well, then I don't see any reason for discussion at all.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #39
"Scott M." <s-***@nospam.nospam> schrieb:
Herfried, take a deep breath. I think we are at the point in this thread
where it's pretty clear we are talking about preferences and you are
trying to "argue" your preference over others. If there was only one
choice, then there wouldn't be a need for preferences.


There are good and bad preferences. But I see, you don't like in-depth
discussion and evaluation of arguments.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

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

"Jay B. Harlow [MVP - Outlook]" wrote:
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/arc...6/07/1200.aspx
Hope this helps
Jay
"rawCoder" <ra******@hotmail.com> wrote in message
news:uE**************@TK2MSFTNGP14.phx.gbl...
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


Nov 21 '05 #41
In depth discussion is fine and as I've said, it seems that we've played
that out as most of the last posts are now talking about how people prefer
this or that. Since the in depth discussion has pretty much resulted in a
consensus that for the most part using either syntax is equivalent, we are
now talking about preferences. If A = B then it is hard to say that A is
bad but B is good.


"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uD*************@tk2msftngp13.phx.gbl...
"Scott M." <s-***@nospam.nospam> schrieb:
Herfried, take a deep breath. I think we are at the point in this thread
where it's pretty clear we are talking about preferences and you are
trying to "argue" your preference over others. If there was only one
choice, then there wouldn't be a need for preferences.


There are good and bad preferences. But I see, you don't like in-depth
discussion and evaluation of arguments.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

Nov 21 '05 #42
Dennis <De****@discussions.microsoft.com> wrote:
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?


If that's the case, it's no longer a compatible language with the
existing VB.NET, basically.

Fortunately, I don't think MS is stupid enough to do that. There's
already an integer type which is 8 bytes long, and if they need to
introduce new, larger types, they can give them new names. That way we
won't get into the message C is in.

--
Jon Skeet - <sk***@pobox.com>
http://www.pobox.com/~skeet
If replying to the group, please do not mail me too
Nov 21 '05 #43
"Dennis" <De****@discussions.microsoft.com> schrieb:
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?


The datatypes will remain in their current size, which means that an
'Integer' (= 'Int32') will /always/ be 32-bit, and 'Integer' will /always/
map to 'Int32'.

--
M S Herfried K. Wagner
M V P <URL:http://dotnet.mvps.org/>
V B <URL:http://dotnet.mvps.org/dotnet/faqs/>

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

"Dennis" <De****@discussions.microsoft.com> wrote in message
news:B3**********************************@microsof t.com...
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?

"Jay B. Harlow [MVP - Outlook]" wrote:
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/arc...6/07/1200.aspx
Hope this helps
Jay
"rawCoder" <ra******@hotmail.com> wrote in message
news:uE**************@TK2MSFTNGP14.phx.gbl...
> 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
>
>


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

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.