cint and int32.parse

[Jim in Arizona]

I'm familiar with CInt(value) but I'm not with Int32.Parse(val ue). 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.Par seString...and that sure looks like a method call to me
;) Even the IL calls IntegerType.Par seString, 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 ArgumentNullExc eption.

If you want to see how the "guts" of CInt works, open up Reflector and
load the Microsoft.Visua lBasic assembly. From there, drill down to
Microsoft.Visua lBasic.Compiler Services.Intege rType. 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(val ue). 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.Visua l 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*******@hotm ail.com> schrieb:

I'm familiar with CInt(value) but I'm not with Int32.Parse(val ue). 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.panopticonc entral.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******** ******@TK2MSFTN GP10.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.Par seString...and that sure looks like a method call to me ;)
Even the IL calls IntegerType.Par seString, 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 ArgumentNullExc eption.

If you want to see how the "guts" of CInt works, open up Reflector and
load the Microsoft.Visua lBasic assembly. From there, drill down to
Microsoft.Visua lBasic.Compiler Services.Intege rType. 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******** ******@TK2MSFTN GP12.phx.gbl...

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

I'm familiar with CInt(value) but I'm not with Int32.Parse(val ue). 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.panopticonc entral.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******** ********@TK2MSF TNGP10.phx.gbl. ..

Jim,

To say it very simple.

First of all are it less characters to type.

Second have the Microsoft.Visua l 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.