cint and int32.parse

  • Thread starter Thread starter Jim in Arizona
  • Start date Start date
J

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
 
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,

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
 
Adam Goossens said:
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.
Click to expand...

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
 
Cor Ligthert said:
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
Click to expand...

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?
 
Jim,
If I use CInt(), is the default data type a 32 bit integer?
Click to expand...

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
 
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,

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.
Click to expand...

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.
 
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.
Click to expand...
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,

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.
Click to expand...

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.
 
David said:
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.
Click to expand...

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

I did not think on unboxing.

In that case you are right.

Thanks for pointing me on that.

Cor
 
Herfried,
As 'String' is not a value type, no unboxing is going in our particular
case.
Click to expand...

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
 
'DirectCast' has already been available in VB.NET 2002.
Click to expand...

Thanks for the correction. I don't know where I got the idea that it
might not have been there.
 
You must log in or register to reply here.

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Similar Threads

CInt produce System.ArgumentException: "currency separator information is ambiguous for parsing" 14
Difference between Cint and Convert.ToInt32 ? 4
Too many items in listbox? 3
what is the difference wetween Int32.parse and Convert.ToInt32 3
syntax for EnumPrinters printer object 1
convert Int32 Unicode character code to its value 2
Out of Memory Error w/Image from HBitmap 4
List<String> 15

Back
Top