string > int

[Guest Lews]

How do I convert a string with a number in it to an int?

[divil]

myInt = Int32.Parse(myString);

[Guest Lews]

Thanks, found it already though. Found another way to do it also:

 

myInt = Convert.ToInt64(myString);

 

Actually the Convert-class seems to be able to convert a lot of things =).

[Robby]

or even Ctype()

[divil]

CType is just a VB.NET thing, I try to avoid it.

[Robby]

I've been searching for benchmarks or opinions on which is best;

convert, parse or ctype.

 

Any opinions?

[wyrd]

I did minor (note, minor) benchmarking on CType and CStr/CInt/etc. No difference in speed. I read somewhere that DirectCast is supposed to be faster, but it's only for casting a reference type to another reference type.

[divil]

Personally I see CType as bad practice, just as I see using other VB.NET specific methods to be. As far as I see it, if you're using .net you might as well use the methods of the .net framework, it makes the transition to another .net language much easier.

 

Use DirectCast to cast, and the framework methods to convert. (If you're using VB.NET).

[wyrd]

Divil:

 

I hate to strongly disagree with a guru of .NET, but I do. That's like saying people shouldn't use (int) or (double) or whatever to cast in C#. People coming from C++ or Java will no doubtedly cast that way while coding in C# since the syntax resemble those languages to begin with. Using a specific method to cast that's only available in a specific language is not going to hinder someone in learning a different .NET language, especially since VB.NET is the only one that even does casting like CInt() while the rest use (int) style.

 

Unless I am somehow using the Microsoft.VisualBasic namespace or CInt is somehow slower then Convert.ToInt16 (or whatever Int## it is) I see no reason to do needless typing. I also find CInt far more easier to read then Convert.ToInt16 or 32 or whatever ## represents an Integer.

 

To be honest I think VB.NET should adopt the (type) casting. I find that the easiest to use and most readable out of them all, and it's also used in C#, C++ and Java.

 

Now if CInt etc style casting was old legacy VB6 code in the Microsoft.VisualBasic namespace then I'd fully agree. Since it's not (at least I hope not otherwise I'm just making myself look like a fool here :eek:), it's going to be supported by VB.NET probably indefinitely as it's part of the language itself, just like (type) style casting is with C++, Java and C#.

[Derek Stone]

Well, they are in Microsoft.VisualBasic, but you're confusing Microsoft.VisualBasic with Microsoft.VisualBasic.Compatibility. The former is fine to use, as it is part of the framework and contains the VB.NET runtimes. The latter is an absolute no-no.

[wyrd]

Hmm.. maybe I am confusing the namespaces. I general stay away from anything that comes from any namespace with VisualBasic in it if possible.

 

I flipped through the namespaces and even did a search in the object browser, couldn't find CType or CInt, etc anywhere. :confused:

[Derek Stone]

You have to click the Microsoft.VisualBasic node in MSDN and then look for the link to the VB.NET reference.

[wyrd]

Edit:

Wrong thread *slaps self*

Edited December 5, 2002 by wyrd

[divil]

wyrd, what else are you going to use in C# to cast except (type) ?

 

You can use CType or DirectCast to cast types in VB.NET, DirectCast is faster. I rest my case.

[wyrd]

wyrd, what else are you going to use in C# to cast except (type) ?

 

The Convert class. Convert.ToString, etc.. There is also Integer.Parse etc as well.

 

You can use CType or DirectCast to cast types in VB.NET, DirectCast is faster. I rest my case.

 

DirectCast only casts reference types. It does not cast value types.

[divil]

There's no such thing as casting value types!

 

I don't know how much you know about casting, but you cast a class to a subclass or superclass of it. Casting and converting are two different things. Casting operators are part of a language, converting (in this case) is supplied by the framework via the Convert class (and others).

[wyrd]

Maybe Microsoft changed the terminology for .NET, but in Java it is all referred to as casting (the (type) is called the cast operator). If my memory serves correctly, a teacher in my school has never even referred to casting as converting.

 

However the book I am reading "Programming Visual Basic .NET" by Francesco Balena publishedy by Wintellect uses the terminology cast AND convert for both CType and DirectCast. A quote from the book;

"You do this by manually converting (or coercing, or casting) the object to the target type"

 

It seems to me that convert and cast means the same thing.

[divil]

Not at all. A String is an Object with more methods, you can cast from one to the other. It's the same object, just different ways of looking at it. But you cannot just cast an integer as, say, a double. There's no way of looking at an integer which makes it look like a double. You have to convert the value of it.

 

I avoid using CType in VB because it's designed to do both if need be, which is quite nice in a way but if you know what you want to do, why not do it explicitly and same those extra CPU cycles? To cast objects you have the DirectCast keyword, which (for casting objects) is faster than CType. To convert between value types you have the Convert types, which will also be faster than using CType.

 

Comes down to personal preference I suppose, but these are just my two pennies worth. I know the difference between casting and converting.

[wyrd]

Well, I see what you're saying. Casting reference types vs casting value types (which is like I said above DirectCast can only cast reference types).

 

Now I know you say converting for value types and casting for reference types, but to me convert and cast are the same definition, the only difference is the type of variable you are casting.

 

Please before you reply know that I understand fully what you mean. I'm just trying to clear up what I was referring to when I was talking about casting.

 

With all this said, I'm going to yield my arguement. I have been only programming VB6 off and on for a year and .NET for only maybe a month. I'm sure you have had way more experience, especially in the "real world" where it counts, so your terminology is probably far more correct then what I've been taught so far in school.