Difference between DirectCast() and CType() in VB.NET

Question

I am an experienced C/C++/C# programmer who has just gotten into VB.NET. I generally use CType (and CInt, CBool, CStr) for casts because it is fewer characters and was the first way of casting which I was exposed to, but I am aware of DirectCast and TryCast as well.

Simply, are there any differences (effect of cast, performance, etc.) between DirectCast and CType? I understand the idea of TryCast.

Exact duplicate of this *Casting DataTypes with DirectCast, CType, TryCast* http://stackoverflow.com/questions/2703585/casting-datatypes-with-directcast-ctype-trycast — MarkJ, Jun 17 '10 at 18:18
Possible duplicate of [Casting DataTypes with DirectCast, CType, TryCast](https://stackoverflow.com/questions/2703585/casting-datatypes-with-directcast-ctype-trycast) — Imad, Jun 05 '17 at 08:37

Joel Coehoorn · Accepted Answer · 2020-12-08T01:52:01.383

202

The first thing to note is VB.NET does not have a direct analog to C#'s (type)instance casting mechanism. I bring this up because it's useful as a starting point and common reference in comparing the two VB.NET operators (and they are operators, not functions, even though they have function semantics).

DirectCast() is more strict than the C# casting operator. It only allows you to cast when the item being cast already is the type you are casting to. I believe it will still unbox value types, but otherwise it won't do any conversion. So, for example, you can't cast from short to int, like you could with a C# (int) cast. But you can cast from an IEnumerable to an array, if your underlying IEnumerable object variable really is an Array. And of course you can cast from Object to anything, assuming the type of your object instance really is somewhere below your cast type in the inheritance tree.

This is desirable because it's much faster. There's less conversion and type checking that needs to take place.

CType() is less strict than the C# casting operator. It will do things you just can't do with a simple (int)-style cast, like convert a string to an integer. It has as much power as calling Convert.To___() in C#, where the ___ is the target type of your cast.

This is desirable because it's very powerful. However, this power comes at the cost of performance; it's not as fast as DirectCast() or C#'s cast operator because it might need to do quite a lot of work to finish the cast. Generally you should prefer DirectCast() when you can.

Finally, you missed one casting operator: TryCast(), which is a direct analog to C#'s as operator.

edited Dec 08 '20 at 01:52

answered Jun 16 '10 at 19:37

Joel Coehoorn

399,467
113
570
794

27

+1 I'd say the strictness of `DirectCast` is another advantage. If you make a mistake the compiler tells you immediately, but with `CType` a mistake just might cause occasional wrong behaviour at run-time - maybe on some user machine with different regional settings. – MarkJ Jun 17 '10 at 18:25
2

Great answer. So in order of complexity (small to large): `DirectCast`, `TryCast`, `CType`/`Convert.ToXYZ()`, `C()` would be correct? – motto Aug 30 '10 at 21:53
3

@motto - close. The C() "functions" should be moved higher on the list, as they really are operators rather than functions, even though they have function semantics. For those types that have them, they are very close to C#'s (type)casting, but will do just a little more work. – Joel Coehoorn Aug 30 '10 at 22:16
3

@MarkJ +1 for your comment, but note `DirectCast` is only strict with classes, not interfaces (because you can have COM types -- and perhaps others -- that actually implement interfaces not defined by the .NET Type's `.GetInterfaces` list). – Mark Hurd Feb 22 '13 at 16:27
2

@JoelCoehoorn +1, But actually, `TryCast()` and `as` are not exactly the same. `TryCast()` only works with reference types, while `as` works with anything that can be null. So `int? icast = myNum as int?;` will work just fine, but `Dim icast as Integer? = TryCast(myNum, Integer?)` will give a compiler error. Just one more peculiar difference between the two languages. lol – CptRobby Dec 16 '14 at 23:22
Also see [Han Passant's answer](https://stackoverflow.com/a/2704915/199364) to an earlier, similar, question, for an example of the risks of the non-strictness of `CType`. IMHO, such risks are more important than performance or a few extra characters to type - use `DirectCast` unless you really need `CType`. – ToolmakerSteve May 23 '17 at 16:03
DirectCast is usually too pedantic because you can't even cast an Integer to a Double – symbiont Sep 04 '19 at 10:55

score 12 · Answer 2 · edited Jun 11 '21 at 18:08

12

With CType you can write something like Ctype("string",Integer). But with DirectCast the above statement would give a compile time error.

 Dim a As Integer = DirectCast("1", Integer) 'Gives compiler error
 Dim b As Integer = CType("1", Integer) 'Will compile

edited Jun 11 '21 at 18:08

Peter Mortensen

30,738
21
105
131

answered Jul 05 '11 at 14:50

Abhay

121
1
2

score 0 · Answer 3 · edited Jun 25 '18 at 08:17

DirectCast is more restrictive than CType.

For example, this will throw an error:

Sub Main()
    Dim newint As Integer = DirectCast(3345.34, Integer)
    Console.WriteLine(newint)
    Console.ReadLine()
End Sub

It will also be shown in the Visual Studio IDE.

This however, does not throw an error:

Sub Main()
    Dim newint As Integer = CType(3345.34, Integer)
    Console.WriteLine(newint)
    Console.ReadLine()
End Sub

Difference between DirectCast() and CType() in VB.NET

3 Answers3

Linked