When to Use a Cast or Convert

When to use a Cast or Convert

~~See Diff Between Cast and Convert on another forum~~

Answer

The Convert.ToInt32(String, IFormatProvider) underneath calls the Int32.Parse (read remarks).

So the only difference is that if a null string is passed it returns 0, whereas Int32.Parse throws an ArgumentNullException.

It is really a matter of choice whichever you use.

Personally, I use neither, and tend to use the TryParse functions (e.g. System.Int32.TryParse()).

UPDATE

Link on top is broken, see this answer on StackOverflow.

Difference between casting and using the Convert.To() method

Even if you may see them somehow as equivalent they're completely different in purpose. Let's first try to define what a cast is:

Casting is the action of changing an entity of one data type into another.

It's a little bit generic and it's somehow equivalent to a conversion because a cast often has the same syntax of a conversion so the question should be when a cast (implicit or explicit) is allowed by the language and when do you have to use a (more) explicit conversion?

Let me first draw a simple line between them. Formally (even if equivalent for language syntax) a cast will change the type while a conversion will/may change the value (eventually together with the type). Also a cast is reversible while a conversion may not be.

This topic is pretty vast so let's try to narrow it a little bit by excluding custom cast operators from the game.

Implicit casts

In C# a cast is implicit when you won't lose any information (please note that this check is performed with types and not with their actual values).

Primitive types

For example:

int tinyInteger = 10;
long bigInteger = tinyInteger;

float tinyReal = 10.0f;
double bigReal = tinyReal;

These casts are implicit because during the conversion you won't lose any information (you just make the type wider). Vice versa implicit cast isn't allowed because, regardless of their actual values (because they can be checked only at run-time), during the conversion you may lose some information. For example this code won't compile because a double may contain (and actually it does) a value not representable with a float:

// won't compile!
double bigReal = Double.MaxValue;
float tinyReal = bigReal;

Objects

In case of an object (a pointer to) the cast is always implicit when the compiler can be sure that the source type is a derived class (or it implements) the type of the target class, for example:

string text = "123";
IFormattable formattable = text;

NotSupportedException derivedException = new NotSupportedException();
Exception baseException = derivedException;

In this case the compiler knows that string implements IFormattable and that NotSupportedException is (derives from) Exception so the cast is implicit. No information is lost because objects don't change their types (this is different with structs and primitive types because with a cast you create a new object of another type), what changes is your view of them.

Explicit casts

A cast is explicit when the conversion isn't done implicitly by the compiler and then you must use the cast operator. Usually it means that:

You may lose information or data so you have to be aware of it.
The conversion may fail (because you can't convert one type to the other) so, again, you must be aware of what you're doing.

Primitive types

An explicit cast is required for primitive types when during the conversion you may lose some data, for example:

double precise = Math.Cos(Math.PI * 1.23456) / Math.Sin(1.23456);
float coarse = (float)precise;

float epsilon = (float)Double.Epsilon;

In both examples, even if the values fall within the float range, you'll lose information (in this case precision) so the conversion must be explicit. Now try this:

float max = (float)Double.MaxValue;

This conversion will fail so, again, it must be explicit so you're aware of it and you may do a check (in the example the value is constant but it may come from some run-time computations or I/O). Back to your example:

// won't compile!
string text = "123";
double value = (double)text;

This won't compile because the compiler can't convert text to numbers. Text may contain any characters, not numbers only and this is too much, in C#, even for an explicit cast (but it may be allowed in another language).

Objects

Conversions from pointers (to objects) may fail if the types are unrelated, for example this code won't compile (because the compiler knows there is no possible conversion):

// won't compile!    
string text = (string)AppDomain.Current;
Exception exception = (Exception)"abc";

This code will compile but it may fail at run-time (it depends on the effective type of casted objects) with an InvalidCastException:

object obj = GetNextObjectFromInput();
string text = (string)obj;

obj = GetNextObjectFromInput();
Exception exception = (Exception)obj;

Conversions

So, finally, if casts are conversions then why do we need classes like Convert? Ignoring the subtle differences that come from Convert implementation and IConvertible implementations actually because in C# with a cast you say to the compiler:

trust me, this type is that type even if you can't know it now, let me do it and you'll see.

-or-

don't worry, I don't care if something will be lost in this conversion.

For anything else a more explicit operation is needed (think about implications of easy casts, that's why C++ introduced long, verbose and explicit syntax for them). This may involve a complex operation (for string -> double conversion a parsing will be needed). A conversion to string, for example, is always possible (via ToString() method) but it may mean something different from what you expect so it must be more explicit than a cast (more you write, more you think about what you're doing).

This conversion can be done inside the object (using known IL instructions for that), using custom conversion operators (defined in the class to cast) or more complex mechanisms (TypeConverters or class methods, for example). You're not aware of what will happen to do that but you're aware it may fail (that's why IMO when a more controlled conversion is possible you should use it). In your case the conversion simply will parse the string to produce a double:

double value = Double.Parse(aStringVariable);

Of course this may fail so if you do it you should always catch the exception it may throw (FormatException). It's out of topic here but when a TryParse is available then you should use it (because semantically you say it may not be a number and it's even faster...to fail).

Conversions in .NET can come from a lot of places, TypeConverter, implicit/explicit casts with user defined conversion operators, implementation of IConvertible and parsing methods (did I forget something?). Take a look on MSDN for more details about them.

To finish this long answer just few words about user defined conversion operators. It's just sugar to let the programmer use a cast to convert one type to another. It's a method inside a class (the one that will be casted) that says "hey, if he/she wants to convert this type to that type then I can do it". For example:

float? maybe = 10; // Equals to Nullable<float> maybe = 10;
float sure1 = (float)maybe; // With cast
float sure2 = maybe.Value; // Without cast

In this case it's explicit because it may fail but this is let to the implementation (even if there are guidelines about this). Imagine you write a custom string class like this:

EasyString text = "123"; // Implicit from string
double value = (string)text; // Explicit to double

In your implementation you may decide to "make programmer's life easier" and to expose this conversion via a cast (remember it's just a shortcut to write less). Some language may even allow this:

double value = "123";

Allowing implicit conversion to any type (check will be done at run-time). With proper options this can be done, for example, in VB.NET. It's just a different philosophy.

What can I do with them?

So the final question is when you should use one or another. Let's see when you can use an explicit cast:

Conversions between base types.
Conversions from object to any other type (this may include unboxing too).
Conversions from a derived class to a base class (or to an implemented interface).
Conversions from one type to another via custom conversion operators.

Only the first conversion can be done with Convert so for the others you have no choice and you need to use an explicit cast.

Let's see now when you can use Convert:

Conversions from any base type to another base type (with some limitations, see MSDN).
Conversions from any type that implements IConvertible to any other (supported) type.
Conversions from/to a byte array to/from a string.

Conclusions

IMO Convert should be used each time you know a conversion may fail (because of the format, because of the range or because it may be unsupported), even if the same conversion can be done with a cast (unless something else is available). It makes clear to who will read your code what's your intent and that it may fail (simplifying debug).

For everything else you need to use a cast, no choice, but if another better method is available then I suggest you use it. In your example a conversion from string to double is something that (especially if text comes from user) very often will fail so you should make it as much explicit as possible (moreover you get more control over it), for example using a TryParse method.

Edit: what's the difference between them?

According to updated question and keeping what I wrote before (about when you can use a cast compared to when you can/have to use Convert) then last point to clarify is if there are difference between them (moreover Convert uses IConvertible and IFormattable interfaces so it can perform operations not allowed with casts).

Short answer is yes, they behave differently. I see the Convert class like a helper methods class so often it provides some benefit or slightly different behaviors. For example:

double real = 1.6;
int castedInteger = (int)real; // 1
int convertedInteger = Convert.ToInt32(real); // 2

Pretty different, right? The cast truncates (it's what we all expect) but Convert performs a rounding to nearest integer (and this may not be expected if you're not aware of it). Each conversion method introduces differences so a general rule can't be applied and they must be seen case by case...19 base types to convert to every other type...list can be pretty long, much better to consult MSDN case by case!

T-SQL Cast versus Convert

CONVERT is SQL Server specific, CAST is ANSI.

CONVERT is more flexible in that you can format dates etc. Other than that, they are pretty much the same. If you don't care about the extended features, use CAST.

EDIT:

As noted by @beruic and @C-F in the comments below, there is possible loss of precision when an implicit conversion is used (that is one where you use neither CAST nor CONVERT). For further information, see CAST and CONVERT and in particular this graphic: SQL Server Data Type Conversion Chart. With this extra information, the original advice still remains the same. Use CAST where possible.

Proper time to cast vs. convert in c#

You can use cast in two cases:

when type you are casting to IS a type you are casting from
when explicit cast operator defined for these types

In all other cases you should use Convert or other custom conversion method (e.g. DateTime.Parse).

why do they return different results?

Because different code is executed. Convert.ToInt32(double value) rounds result of casting:

int num = (int) value;
double num2 = value - num;
if ((num2 > 0.5) || ((num2 == 0.5) && ((num & 1) != 0)))    
    num++;

return num;

SQL Server cast() vs convert()

From this link :

CAST is an ANSI standard while CONVERT is a specific function in the SQL server. There are also differences when it comes to what a particular function can and cannot do.
For example, a CONVERT function can be used for formatting purposes especially for date/time, data type, and money/data type. Meanwhile, CAST is used to remove or reduce format while still converting. Also, CONVERT can stimulate set date format options while CAST cannot do this function.
CAST is also the more portable function of the two. It means that the CAST function can be used by many databases. CAST is also less powerful and less flexible than CONVERT. On the other hand, CONVERT allows more flexibility and is the preferred function to use for data, time values, traditional numbers, and money signifiers. CONVERT is also useful in formatting the data’s format.
CAST functions also restore the decimals and numerical values to integers while converting. It also can be used to truncate the decimal portion or value of an integer.

What is the difference between casting and conversion?

I believe what Eric is trying to say is:

Casting is a term describing syntax (hence the Syntactic meaning).

Conversion is a term describing what actions are actually taken behind the scenes (and thus the Semantic meaning).

A cast-expression is used to convert
explicitly an expression to a given
type.

And

A cast-expression of the form (T)E,
where T is a type and E is a
unary-expression, performs an explicit
conversion (§13.2) of the value of E
to type T.

Seems to back that up by saying that a cast operator in the syntax performs an explicit conversion.

Is casting the same thing as converting?

The simple answer is: it depends.

For value types, casting will involve genuinely converting it to a different type. For instance:

float f = 1.5f;
int i = (int) f; // Conversion

When the casting expression unboxes, the result (assuming it works) is usually just a copy of what was in the box, with the same type. There are exceptions, however - you can unbox from a boxed int to an enum (with an underlying type of int) and vice versa; likewise you can unbox from a boxed int to a Nullable<int>.

When the casting expression is from one reference type to another and no user-defined conversion is involved, there's no conversion as far as the object itself is concerned - only the type of the reference "changes" - and that's really only the way that the value is regarded, rather than the reference itself (which will be the same bits as before). For example:

object o = "hello";
string x = (string) o; // No data is "converted"; x and o refer to the same object

When user-defined conversions get involved, this usually entails returning a different object/value. For example, you could define a conversion to string for your own type - and
this would certainly not be the same data as your own object. (It might be an existing string referred to from your object already, of course.) In my experience user-defined conversions usually exist between value types rather than reference types, so this is rarely an issue.

All of these count as conversions in terms of the specification - but they don't all count as converting an object into an object of a different type. I suspect this is a case of Jesse Liberty being loose with terminology - I've noticed that in Programming C# 3.0, which I've just been reading.

Does that cover everything?

Whats is the difference between using Convert and Cast in a Select statement

No, performance is not a issue.(As far as your question describes both can be used and there is no difference between them but as martin said statement using CAST will cast to varchar(30) as it is it's default length)

CAST is an ANSI SQL-92

CONVERT is specific to SQL Server

CONVERT is specific to SQL Server, and allows for a greater breadth of flexibility when converting between date and time values, fractional numbers, and monetary signifiers.

Try this

SELECT DISTINCT CONVERT(VARCHAR(MAX), GETDATE(),108)
--and the other is saying to use

select distinct cast(GETDATE() as VARCHAR(MAX))

datetime Cast or Convert?

convert has an optional parameter style, and I suggest to use convert instead of cast. It helps to avoid confusion.
For example, if you write cast('20130302' as date), what would you get? March 2 or February 3?

Also, if you want specific format when casting to date to string, you bound to use convert

When to Use a Cast or Convert