cint and int32.parse

[Jim in Arizona]

I'm familiar with CInt(value) but I'm not with Int32.Parse(value). They seem
to do the same thing. Is there a big difference between the two and when
would one be best applied over the other?

Thanks,
Jim

[Adam Goossens]

Hi Jim,

According to the documentation, the biggest difference between
CInt/CStr/C<Etc> is that the code to coerce the variable to the correct
type (integer in this case) is compiled inline.

This makes it's performance (apparently) faster than Int32.Parse as
there is no method call.

I disagree with the above statements, because when I compile code that
uses CInt("3"), the CInt() call is converted to
IntegerType.ParseString...and that sure looks like a method call to me
;) Even the IL calls IntegerType.ParseString, so I don't know about all
these "inline" claims.

The built-in conversion functions (C<etc>) do some extra checks before
they try to cast the type. For example, CInt will return 0 if you pass
Nothing, but Int32.Parse will throw an ArgumentNullException.

If you want to see how the "guts" of CInt works, open up Reflector and
load the Microsoft.VisualBasic assembly. From there, drill down to
Microsoft.VisualBasic.CompilerServices.IntegerType . The various methods
in that module do the conversion.

Regards,
-Adam.

Jim in Arizona wrote:

I'm familiar with CInt(value) but I'm not with Int32.Parse(value). They seem
to do the same thing. Is there a big difference between the two and when
would one be best applied over the other?

Thanks,
Jim

[Cor Ligthert]

Jim,

To say it very simple.

First of all are it less characters to type.

Second have the Microsoft.Visual Basic conversion methods in some cases some
extras that can improve speed or automatic handling in situations where you
should need with the parse extra commands.

In fact they should do the same, I find the conversions commands beside the
IDE one of the strongest part of VBNet.

(You did not mention it, there is as well a convert class)

Just my thought,

Cor

[Herfried K. Wagner [MVP]]

"Jim in Arizona" <ti*******@hotmail.com> schrieb:

I'm familiar with CInt(value) but I'm not with Int32.Parse(value). They
seem to do the same thing. Is there a big difference between the two and
when would one be best applied over the other?

In addition to the other replies:

Conversion operators in VB
<URL:http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx>

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

[Jim in Arizona]

"Adam Goossens" <ad***********@gmail.com> wrote in message
news:uB**************@TK2MSFTNGP10.phx.gbl...

Hi Jim,

According to the documentation, the biggest difference between
CInt/CStr/C<Etc> is that the code to coerce the variable to the correct
type (integer in this case) is compiled inline.

This makes it's performance (apparently) faster than Int32.Parse as there
is no method call.

I disagree with the above statements, because when I compile code that
uses CInt("3"), the CInt() call is converted to
IntegerType.ParseString...and that sure looks like a method call to me ;)
Even the IL calls IntegerType.ParseString, so I don't know about all these
"inline" claims.

The built-in conversion functions (C<etc>) do some extra checks before
they try to cast the type. For example, CInt will return 0 if you pass
Nothing, but Int32.Parse will throw an ArgumentNullException.

If you want to see how the "guts" of CInt works, open up Reflector and
load the Microsoft.VisualBasic assembly. From there, drill down to
Microsoft.VisualBasic.CompilerServices.IntegerType . The various methods in
that module do the conversion.

Regards,
-Adam.

That is some very good insight into the subject. I'm new to VB.NET and was
still fairly new with VB6 before I decided to go with .NET and try not to
look back.

I was reading a book on VB.NET and the author used CInt() in an early
chapter then was using Int32.Parse() in subsequent chapters, without
explaining why he chose one over the other.

I'm not familiar with Reflector or the assembly so your last paragraph went
wooosh right over my head. I'll get there someday.

Thanks Adam,
Jim

[Jim in Arizona]

"Herfried K. Wagner [MVP]" <hi***************@gmx.at> wrote in message
news:uo**************@TK2MSFTNGP12.phx.gbl...

"Jim in Arizona" <ti*******@hotmail.com> schrieb:

I'm familiar with CInt(value) but I'm not with Int32.Parse(value). They
seem to do the same thing. Is there a big difference between the two and
when would one be best applied over the other?

In addition to the other replies:

Conversion operators in VB
<URL:http://www.panopticoncentral.net/archive/2004/06/07/1200.aspx>

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

Following your document, I ended up here:

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

And when you take a look at the appendix at the bottom, you'll see that the
recommendation is to go ahead and use CType for most conversions.

Thanks,
Jim

[Jim in Arizona]

"Cor Ligthert" <no************@planet.nl> wrote in message
news:%2****************@TK2MSFTNGP10.phx.gbl...

Jim,

To say it very simple.

First of all are it less characters to type.

Second have the Microsoft.Visual Basic conversion methods in some cases
some extras that can improve speed or automatic handling in situations
where you should need with the parse extra commands.

In fact they should do the same, I find the conversions commands beside
the IDE one of the strongest part of VBNet.

(You did not mention it, there is as well a convert class)

Just my thought,

Cor

I didn't know there was a convert class as well, so I gave that a try:
Convert.ToInt32()
I don't quite understand why there would be so many different ways to
achieve the same result. I find that it makes learning the language much
more time consuming.

If I use CInt(), is the default data type a 32 bit integer?

[Cor Ligthert]

Jim,

If I use CInt(), is the default data type a 32 bit integer?

Where you can can, you would you use in Net the Integer, which is at the
moment the Int32. That is confirming the processer word lengtht and
therefore the most efficient.

CInt does that Integer.

I hope this helps,

Cor

[Adam Goossens]

Jim,

The Convert.To<Type> functions are designed to be used from any language
in the framework. It's a central "one stop shop for all your intrinsic
type conversion needs". :)

The CInt/CStr/CBool/Etc functions are mostly to maintain compatibility
with the previous versions of Visual Basic.

The biggest advantage of the functions in the Convert class is that they
provide you with a lot more choices when you perform the conversion, for
example:

---
Dim i as Integer

i = Convert.ToInt32("0xFF", 16) ' converts the Hexadecimal number 0xFF
to an integer (255).
---

As long as you stick with the CInt/CStr/Etc functions for your basic
type conversion, you'll have no troubles at all. The functions in the
Convert class are really for the more specialized needs (like the
conversion from a hex string to an integer above).

Regards,
-Adam.

Jim in Arizona wrote:

I didn't know there was a convert class as well, so I gave that a try:
Convert.ToInt32()
I don't quite understand why there would be so many different ways to
achieve the same result. I find that it makes learning the language much
more time consuming.

If I use CInt(), is the default data type a 32 bit integer?

[David]

On 2005-04-12, Adam Goossens <ad***********@gmail.com> wrote:

Jim,

The Convert.To<Type> functions are designed to be used from any language
in the framework. It's a central "one stop shop for all your intrinsic
type conversion needs". :)

The CInt/CStr/CBool/Etc functions are mostly to maintain compatibility
with the previous versions of Visual Basic.

The only thing I'd add is that the CInt/CStr functions aren't really
functions, they're language keywords, and will result in different code
depending on the declarations of their parameters.

I'd agree that it doesn't much matter which of the many available
conversion techniques one uses, although I do think that using a
CInt/Cstr/CType call when you really want a cast is a bad habit, and a
pretty common one.

[Cor Ligthert]

David,

I'd agree that it doesn't much matter which of the many available
conversion techniques one uses, although I do think that using a
CInt/Cstr/CType call when you really want a cast is a bad habit, and a
pretty common one.

Can you explain that above, because in my opinion are it beside the CType
all direct conversion from values. I never was able to cast those.

However tell me what I miss.

Cor

[David]

On 2005-04-12, Cor Ligthert <no************@planet.nl> wrote:

David,

I'd agree that it doesn't much matter which of the many available
conversion techniques one uses, although I do think that using a
CInt/Cstr/CType call when you really want a cast is a bad habit, and a
pretty common one.

Can you explain that above, because in my opinion are it beside the CType
all direct conversion from values. I never was able to cast those.

Sometimes you want a cast, and sometimes you want a conversion. For
example, say you have an ArrayList of strings, and you want the nth
value in a string variable.

Dim s as string = CStr(list(n))
vs.
Dim s as String = DirectCast(list(n), String)
The first is shorter and seems convenient, but it hides errors. Also,
it hides the intention of the code, did the programmer want a cast or a
conversion here?

IIRC, VB.Net 1.0 didn't even have a cast operator, so there's a tendency
to use the two interchangably, and I think that's a mistake. It's not
as bad as Option Strict Off, but it's down that road.

[Herfried K. Wagner [MVP]]

"David" <df*****@woofix.local.dom> schrieb:

IIRC, VB.Net 1.0 didn't even have a cast operator, so there's a tendency
to use the two interchangably, and I think that's a mistake. It's not
as bad as Option Strict Off, but it's down that road.

'DirectCast' has already been available in VB.NET 2002.

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

[Cor Ligthert]

David,

I did not think on unboxing.

In that case you are right.

Thanks for pointing me on that.

Cor

[Herfried K. Wagner [MVP]]

"Cor Ligthert" <no************@planet.nl> schrieb:

I did not think on unboxing.

As 'String' is not a value type, no unboxing is going in our particular
case.

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

[Cor Ligthert]

Herfried,

As 'String' is not a value type, no unboxing is going in our particular
case.

I know however his message pointed me (myself) on boxing of values.

:-)

By the string I use normally the ToString method and do I find it less
relevant.

DirectCast
castclass [mscorlib]System.String

ToString
callvirt instance string [mscorlib]System.Object::ToString()

Cor

[David]

On 2005-04-12, Herfried K. Wagner [MVP] <hi***************@gmx.at> wrote:

"David" <df*****@woofix.local.dom> schrieb:

IIRC, VB.Net 1.0 didn't even have a cast operator, so there's a tendency
to use the two interchangably, and I think that's a mistake. It's not
as bad as Option Strict Off, but it's down that road.

'DirectCast' has already been available in VB.NET 2002.

Thanks for the correction. I don't know where I got the idea that it
might not have been there.