Click here to Skip to main content
Click here to Skip to main content

Cheat Sheet - Casting in VB.NET and C#

By , 22 Sep 2003
 

Introduction

This article describes several casting and type related operations in VB.NET and C#.

Casting in VB.NET

  1. By default in VB, casting is automatically done for you when you assign objects to variables. The objects are then automatically casted to the variables' type.

    This behaviour can be influenced by an option line on top of your code file:

    Option Strict On
    Option Strict Off
    

    When on, casting is strict and not automatic.

  2. Explicit casting can be done with the cast operator CType() or DirectCast():

    textbox = CType(obj, TextBox)
    textbox = DirectCast(obj, TextBox)
    

    The difference between the two keywords is that CType succeeds as long as there is a valid conversion defined between the expression and the type, whereas DirectCast requires the run-time type of an object variable to be the same as the specified type. If the specified type and the run-time type of the expression are the same, however, the run-time performance of DirectCast is better than that of CType. DirectCast throws an InvalidCastException error if the argument types do not match.

  3. Testing if an object is of a particular type, can be done with the TypeOf...Is operator:

    If TypeOf obj Is TextBox Then...
    
  4. Obtaining a System.Type object for a given type can be done with the GetType operator:

    Dim t As System.Type
    t = GetType(String)
    MessageBox.Show(t.FullName)
    
  5. Obtaining a System.Type object for a given object can be done with the GetType method:

    Dim t as System.Type
    t = obj.GetType()
    MessageBox.Show(t.FullName)
    

Casting in C#

  1. C# is a strictly typed language. Whenever types don't match, casting is necessary.

    Regular casting in C# follows the C(++) and Java syntax:

    string s = (string)obj;
    

    The casting operator applies to the complete chain on the right of it, so in the following example, not a, but a.b is casted to a Form:

    Form f = (Form)a.b;
    

    To cast parts of the chain, use brackets. In the following example, obj is casted to a Form:

    string s = ((Form)obj).Text;
  2. C# knows an additional casting operator: as.

    The as operator is like a cast except that it yields null on conversion failure instead of raising an exception. In the following situation, btn gets the value null:

    Object obj = new TextBox();
    Button btn = obj as Button;
    
  3. Testing if an object is of a particular type, can be done with the is operator:

    if (obj is TextBox) {...}
    
  4. Obtaining a System.Type object for a given type can be done with the typeof operator:

    System.Type t;
    t = typeof(String);
    MessageBox.Show(t.FullName);
    
  5. Obtaining a System.Type object for a given object can be done with the GetType method:

    System.Type t;
    t = obj.GetType();
    MessageBox.Show(t.FullName);
    

License

This article, along with any associated source code and files, is licensed under A Public Domain dedication

About the Author

Rudi Breedenraedt
Architect Wolters Kluwer Belgium
Belgium Belgium
Member
Rudi is a Software Architect at Wolters Kluwer Belgium.

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
Generaldifference VB/C# in compile-time vs run-time errormemberAlexis Rzewski7 Feb '07 - 4:51 
one BIG difference between C# and VB:
 
C# compiler will never allow
 
int myInt = (int) "3";
 
VB.NET compiler, even with Option Strict ON will always allow
 
Dim myInt as Integer = CType ("3", Integer)
 
Both languages understand the .NET class System.Convert:
 
myInt = System.Convert.ToInt32("3")

QuestionHow about casting arraysmembereschneider10019 Mar '05 - 8:57 
How about and example on casting arrays.
 
Thanks
 
Schneider
AnswerRe: How about casting arraysmembercollinsauve7 Aug '08 - 3:28 
I would like to figure out how to do this to.
This is something like what I would like to do...
 
Public Sub SortMyArray(aValues() as Object)
  if typeof aValues is String() then
    SortStrings(directcast(aValues,string())
  elseif typeof aValues is SomeOtherObject() then
    SortOtherObjects(directcast(aValues,SomeOtherObject())
  end if
End Sub
 
Private Sub SortStrings(asValues() as String)
  'Do the sort
End Sub
Private Sub SortOtherObjects(aValues() as SomeOtherObject)
  'Do the sort
End Sub

GeneralToStringmemberGeorge_Seremetidis28 Sep '04 - 13:40 
I prefer to use ToString rather than CType for certain things. ToString will return an empty string if a column is a NULL in a DataRow. CType will throw an exception on a NULL.
GeneralDon't Forget System.Convert.ChangeTypememberShaun Hayward29 Jun '04 - 7:35 
Good article.
 
Another important conversion method is the System.Convert class's ChangeType method - especially when you're using Reflection.
 
The problem with GetType is that the second parameter must accept the name of the type but cannot accept an instance of System.Type (at least no way that I could find).
 
So you can't do the following:
 
obj2 = CType(SomeValue, obj1.GetType)
 
Confused | :confused:
 
This was a REAL problem when trying to convert strings to an EXACT datatype to use the SetValue method in Reflection. The solution:
 
obj2 = System.Convert.ChangeType(SomeValue, obj1.GetType)
 
Cool | :cool:
 
Something worth investigating and possibly adding to the article.
GeneralRe: Don't Forget System.Convert.ChangeTypememberskjagini6 Sep '05 - 2:56 
awesome
JokeRe: Don't Forget System.Convert.ChangeTypememberArtur M.7 Dec '06 - 21:45 
Thank you for pointing out Convert.ChangeType function. This is more important for me then entire article. Smile | :) Rose | [Rose]
 
P.S. However, this function has one limitation- value has to implement IConvertible interface Frown | :(
GeneralProblems with casting objectsmembersimbakid3 Mar '04 - 3:04 
I have a problem in my code with regard casting. I have a base class object called BaseDAO, a subclass is created from this called CustomerRowSet. I have a function which, through reflection, will create an instance of the subclass.

public static BaseDAO newInstance (DAOAssembly cAssembly, string strProviderID)
{
// lookup instance
BaseDAO cDAO = m_cManager.lookup(cAssembly, strProviderID);
 
if (cDAO != null)
{
Console.WriteLine("Created DAO Instance");
}
else
{
Console.WriteLine("Failed to create specified DAO handler");
}
 
// initialise instance
// TODO:
 
return cDAO;
}

 
I make a call to the newInstance function and test the type of the returned object, thus:
 

DAOAssembly x = new DAOAssembly("DAOTest.dll", "d:", "ds.xml", "d:", "TEST");
Object o = CustomerRowSet.newInstance(x, "SELECT_CUSTOMERS");
if (o is DAOTest.CustomerRowSet)
{
Console.WriteLine("Object is of correct type");
}
else
{
System.Type t;
t = o.GetType();
Console.WriteLine(t.FullName);
}

 
Upon return, execution branches into the else statement and not the if statement, but the output from code is:
 

Created DAO Instance
DAOTest.CustomerRowSet

 
This shows that the returned object is of the correct type yet doesn't execute the if branch of the code. In addition, if I try the following code:
 

CustomerRowSet rs = (CustomerRowSet)CustomerRowSet.newInstance(x, "SELECT_CUSTOMERS");

 
I get an InvalidCastException.
 
Grateful for any suggestions or information, many thanks in advance.
 
Chris.

QuestionDifference between DirectCast and Ctype?memberFruitBatInShades26 Jan '04 - 5:36 
If the specified type and the run-time type of the expression are the same, however, the run-time performance of DirectCast is better than that of CType.
So which function gives the best performance under all circumstances? Can you give an example of what type of conversions cause DirectCast to throw!
 
Thanks
GeneralPlease add pointers to the next update!sussAnonymous4 Oct '03 - 13:20 
Please add pointers in the next update, they are still used in C# and casting can be done with them. I am particularly having trouble with pointers in my COM Interop which involves casting.
GeneralOK, but could be bettersussDavid Bennett30 Sep '03 - 4:23 
>>>C# is a strictly typed language. Whenever types don't match, casting is necessary.
 
This is simply not true. C# allows you to upcast and perform implicit conversions (eg double to int) without needing a cast.
 
The whole issue of implicit vs explicit is not mentioned.
 
The existence of a range of other conversion functions (CInt, CDbl, etc) is ignored. Likewise the Convert functions, ToString(), etc.
 
I'll wait for V2.
GeneralInformativeeditorNishant S23 Sep '03 - 20:14 
Thanks Smile | :)
 
Nish
 

Extending MFC Applications with the .NET Framework [NW] (coming soon...)
Summer Love and Some more Cricket [NW] (My first novel)
Shog's review of SLASMC [NW]
Come with me if you want to live

GeneralCommentsmemberNick Seng23 Sep '03 - 15:21 
Where were you when I just started doing C# & VB.Net? Poke tongue | ;-P
 
Anyway, a couple of comments:
 
1) Your explaination of DirectCast isn't really clear. Maybe it would help if you showed some example.
 
2) I don't really see the difference for point 4 & 5.
 

Besides that good article. A lot of newbie would undoubtably find it helpfull Big Grin | :-D
 










Support Bone

GeneralGoodmemberdog_spawn23 Sep '03 - 13:14 
I liked the style of this article as you consider both C# and VB.NET. I learnt something new - I did not know about the as operator Smile | :)
 
Do any C++ purists agree with me when I say: casting is never needed in good OO design.
 
Even in an XML parser you don't need it. Consider a simple example: if you can always predict what nodes you might need to 'cast' into you can provide a function:
 
CommentElement Node::GetAsComment()
 
...where Node is the superclass of all Xml element nodes.
GeneralRe: GoodmemberFurty23 Sep '03 - 13:36 
dog_spawn wrote:
Do any C++ purists agree with me when I say: casting is never needed in good OO design.
 
Just off the top of my head, here are some examples where very good design in C# requires casting:
 
* Creating a plug-in architecture - try loading and instantiating dynamically assemblies without polymorphic reflection tests and casting.
 
* Using pretty much any of the Asynchronous programming methods in the FCL - all use boxing and un-boxing, which can't be done without casting.
 
* Adding queue items that return values to a the ThreadPool requires boxing and un-boxing, which again is casting.
GeneralRe: Goodmemberdog_spawn24 Sep '03 - 6:34 
You seem to have missed my point. I will try to explain myself better.
 
Obviously using C# requires casting. But that is because most of the framework is not designed as well as it could be. My point is about design not about the way the framework happens to be setup Smile | :)
 
Most of the time we only cast because C# doesn't allow us to make specialized collections easily enough yet. 'generics' will solve that hopefully.
 
No plugin architecture ever needs casting. Any plugin object inherits some interface. Obviously a give program only knows about the interface. If you end up casting using plugin objects your interfaces need redesigning Confused | :confused:
GeneralRe: GoodmemberRudi Breedenraedt25 Sep '03 - 5:22 
First, thanks for the compliment!
 
Concerning your good OO design (btw, I don't know if C++ purists are by definition to be considered as OO purists, but please, let's not start that discussion here...D'Oh! | :doh: ):
 
Casting is in my opinion not a matter of design. Casting originates from the fact that the implementation is done in a strong-typed language. Would you implement in a purely object-oriented language as SmallTalk, then you would never have to cast, since it does no typechecking, and even does not know what casting is...
 
Now, should you design in such a way that casting will not be necessary in an implementation language ? My answer would again be no. Good OO designs are caracterised by their good distribution of responsibilities. Is it a good distribution of responsibility to have the superclass know about all it's (current but also future !?!) subclasses, since it should provide GetAsSubclass methods for each one of them ? I believe the contrary. By the way, as I pointed out, you can only provide GetAs methods for known (=current) subclasses, so you disallow extension by subclassing by 3rd parties. Wasn't OO meant to be extended that way ?
 
Consequently, if C# requires casting, it's not due to bad design (although design could have been better), but due to it's strong-typed character.

GeneralRe: Goodmemberdog_spawn25 Sep '03 - 6:52 
Rudi Breedenraedt wrote:
Consequently, if C# requires casting, it's not due to bad design (although design could have been better), but due to it's strong-typed character.
 
C# is a strongly typed language. However the collections are not, hence my comments about bad design.
 
I think you have got mixed up here D'Oh! | :doh: You do not need casting with a strongly typed language. That is the point of types. C# requires casting so frequently because of the bad design of the collections.
 
Rudi Breedenraedt wrote:
I believe the contrary
 
I agree it is bad design to have GetAsSubclass method Smile | :) However that is a better solution than casting. This problem can be solved by good design. For example GetElementsByTagName in the XML part of the framework should return a list of XmlElements, not a list of XmlNodes as it currently does.
GeneralRe: Goodmemberpeterchen29 Sep '03 - 6:29 
Casting in C# is nothing else than querying for another interface. The cast is verified to be valid. So what?
 

"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."

sighist | Agile Programming | doxygen

GeneralRe: Goodmemberdog_spawn29 Sep '03 - 6:34 
Heh, well 'So what?' is a perfectly practical point of view Smile | :) It kind of misses the point but it's less hard work.
GeneralRe: Goodmemberpeterchen29 Sep '03 - 11:19 
What is the difference between a cast and a QueryInterface in C# ?
 

"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."

sighist | Agile Programming | doxygen

GeneralRe: Goodmemberdog_spawn29 Sep '03 - 11:23 
I assume you already know that Wink | ;)
 
I don't really want to say this again but I will: in good design you do not need to downcast because the type of the object you are dealing with should already be the correct interface. That is basic OO programming using types and I refuse to discuss it anymore. Please have mercy Poke tongue | ;-P
GeneralRe: Goodmemberpeterchen29 Sep '03 - 12:26 
dog_spawn wrote:
Please have mercy
 
No Cool | :cool:
 
If you don't want to discuss it, and you can keep yourself from replying, don't reply.
 
otherwise:
 
dog_spawn wrote:
I assume you already know that
 
lets, for this discussion, assume I don't.
 
dog_spawn wrote:
in good design you do not need to downcast because the type of the object you are dealing with should already be the correct interface
 
This propagates requirement of knowledge of this interface through large parts of the project, In my experience, tight coupling is always the downfall of large projects, so I tend to reduce the coupling to the absolute minimum.
 
Do you accept the "virtue" of QueryInterface - or is this "wrong" too?
 
dog_spawn wrote:
That is basic OO programming using types
 
OO is no religion, just a set of rules that have reasons. In programming, I refuse to accept a rule when noone can tell me the reason.

 

"Vierteile den, der sie Hure schimpft mit einem türkischen Säbel."

sighist | Agile Programming | doxygen

GeneralRe: Goodmemberdog_spawn29 Sep '03 - 13:53 
peterchen wrote:
This propagates requirement of knowledge of this interface through large parts of the project, In my experience, tight coupling is always the downfall of large projects, so I tend to reduce the coupling to the absolute minimum.
 
Sorry, but that is insane. If you are saying pass only Object around that is just madness. You have to know the interface anyway as you have to cast it.
 
You must be winding me up here Cool | :cool: Ok, I get it now - please stop Smile | :)
GeneralRe: GoodmemberRocky Moore23 Sep '03 - 14:14 
dog_spawn wrote:
I learnt something new - I did not know about the as operator
 
Just find out about that one a month or so ago. Quite useful!
 
Rocky Moore <><

GeneralRe: GoodmemberAttila Hajdrik25 Sep '03 - 21:27 
The 'as' and 'is' operator can be very useful if it is used in pair.
 
For example think about a treeview control where you've different grouping levels, where each level has a different treenode derived class.
 
When you've to show different context menus depend on the node type what the user right clicked, then the
 
if (nodTemp is MyNodeLevel1)
{
MyNodeLevel1 nodCurrent = nodTemp as MyNodeLevel1;
 
... code here ...
}
else if
...
...
...
 
And these operators provide cleaner code then the "normal" () type casting.
 
So this is great artticle to point out these things!
 
Attila Hajdrik
GeneralRe: Goodmemberrj4524 Apr '04 - 21:07 
Dog_spawn, Your obviously an Idiot. Go get a book and read it instead of posting a useless negative comment on every damn tutorial.
GeneralRe: GoodmemberNgraham26 May '04 - 4:32 
Dog_spawn - if your such a great developer, why do you even need to read these tutorials, you obviously know everything anyway.
 


 
Nick Graham
GeneralRe: GoodmemberDBuckner26 May '04 - 18:57 
I would like to see a dog spawn example. Anyone else??Blush | :O

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web01 | 2.6.130516.1 | Last Updated 23 Sep 2003
Article Copyright 2003 by Rudi Breedenraedt
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid