string > int

[Lews]

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

 

[Divil]

myInt = Int32.Parse(myString);

 

[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]

Ive 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 its 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 youre 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 youre using VB.NET).

 

[wyrd]

Divil:

I hate to strongly disagree with a guru of .NET, but I do. Thats like saying people shouldnt 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 thats 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 its also used in C#, C++ and Java.

Now if CInt etc style casting was old legacy VB6 code in the Microsoft.VisualBasic namespace then Id fully agree. Since its not (at least I hope not otherwise Im just making myself look like a fool here ), its going to be supported by VB.NET probably indefinitely as its 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 youre 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, couldnt find CType or CInt, etc anywhere.

 

[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*

 

[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]

Theres no such thing as casting value types!

I dont 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. Its the same object, just different ways of looking at it. But you cannot just cast an integer as, say, a double. Theres 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 its 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 youre 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. Im just trying to clear up what I was referring to when I was talking about casting.

With all this said, Im going to yield my arguement. I have been only programming VB6 off and on for a year and .NET for only maybe a month. Im 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 Ive been taught so far in school.