I have a function that casts a double on string values.
string variable = "5.00";
double varDouble = (double)variable;
A code change was checked in and the project builds with the error: System.InvalidCastException: Specified cast is not valid.
However, after doing the following...
string variable = "5.00";
double varDouble = Convert.ToDouble(variable);
...the project builds without any errors.
What is the difference between casting and using the Convert.To() method? Why does casting throw an Exception and using the Convert.To() does not?
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!
Casting is a way of telling the compiler, "I know that you think that this variable is a Bar, but I happen to know more than you; the object is actually a Foo, so let me treat it as if it were a Foo from now on." Then, at runtime, if the actual object turned out to really be a Foo then your code works, if it turns out that the object was not a Foo at all, then you get an exception. (Specifically an System.InvalidCastException.)
Converting on the other hand is a way of saying, "If you give me an object of type Bar I can create a brand new Foo object that represents what is in that Bar object. I won't change the original object, it won't treat the original object differently, it will create something new that is just based on some other value. As to how it will do that, it could be anything. In the case of Convert.ToDouble it will end up calling Double.Parse which has all sorts of complex logic for determining what types of strings represent what numeric values. You could write your own conversion method that mapped strings to doubles differently (perhaps to support some entirely different convention for displaying numbers, such as roman numerals or whatever). A conversion could do anything, but the idea is that you're not really asking the compiler to do anything for you; you are the one writing the code to determine how to create the new object because the compiler, without your help, has no way of knowing how to map (as an example) a string to a double.
So, when do you convert, and when do you cast? In both cases we have some variable of a type, let's say A, and we want to have a variable of type B. If our A object really, actually, under the hood, is a B, then we cast. If it's not really a B, then we need to Convert it, and define how the program is supposed to get a B from an A.
From MSDN:
Explicit conversions (casts): Explicit conversions require a cast operator. Casting is required when information might be lost in the conversion, or when the conversion might not succeed for other reasons. Typical examples include numeric conversion to a type that has less precision or a smaller range, and conversion of a base-class instance to a derived class.
Consider the following example:
double a = 2548.3;
int b;
b = (int)a; //2548 --> information (.3) lost in the conversion
And also:
A cast is a way of explicitly informing the compiler that you intend to make the conversion and that you are aware that data loss might occur.
You could use System.Convert class when you want to convert between non-compatible types. The main difference between casting and convert is compile and run-time. The type conversion exceptions are appeared at run-time , i.e a type cast that fails at run-time will cause an InvalidCastException to be thrown.
Conclusion: In casting you are telling to the compiler that a is really type b and if so the project builds without any errors like this example:
double s = 2;
int a = (int) s;
But in conversion you're saying to the compiler there is a way to create a new object from a of type b, please do it and project builds without any errors but as I said if type cast fails at run-time, it will cause an InvalidCastException to be thrown.
For example the code below is never compile because compiler detect that cannot cast expression of type DateTime to type int:
DateTime s = DateTime.Now;
int a = (int)(s);
But this one is compiled successfully:
DateTime s = DateTime.Now;
int a = Convert.ToInt32(s);
But at run-time you will get InvalidCastException which says:
Invalid cast from 'DateTime' to 'Int32'.
In your example you are attempting to cast a string to a double (non integral type).
An explicit conversion is required for it to work.
And i must point that you could have used Convert.ToDouble instead of Convert.ToInt64 as you can lose the fractional parts of the double value when you convert to an int.
if your variable has the value "5.25" varDouble would have been 5.00 (loss of 0.25 because of the Conversion to Int64)
To answer your question about casting vs converting.
Your cast (an explicit cast) doesn't meet the requirements for an explicit cast. the value you are trying to cast with the cast operator is invalid (i.e non integral).
Visit this MSDN Page for the rules of casting / conversions
The Convert.Double method actually just internally calls the Double.Parse(string) method.
Neither the String type nor the Double type define an explicit/implicit conversion between the two types, so casting will always fail.
The Double.Parse method will look at each character in the string and build a numeric value based on the values of the characters in the string. If any of the characters are invalid, the Parse method fails (causing the Convert.Double method to fail as well).
Casting does not involve any conversion, i.e. the internal representation of a value is not changed. Example:
object o = "Hello"; // o is typed as object and contains a string.
string s = (string)o; // This works only if o really contains a string or null.
You can convert a double to string like this
double d = 5;
string s = d.ToString(); // -> "5"
// Or by specifying a format
string formatted = d.ToString("N2"); // -> "5.00"
You can convert a string to a double in several ways (here just two of them):
string s = "5";
double d = Double.Parse(s); // Throws an exception if s does not contain a valid number
Or the safe way
string s = "5";
double d;
if (Double.TryParse(s, out d)) {
Console.WriteLine("OK. Result = {0}", d);
} else {
Console.WriteLine("oops!");
}
double varDouble = (double)variable assumes that variable is already a double. If variable isn't a double (it's a string) then this will fail.
double varDouble = Convert.ToDouble(variable) does like it says - it converts. If it can parse or otherwise extract a double from variable then it will.
I second using Double.Parse or Double.TryParse because it more clearly indicates what's supposed to be happening. You're starting with a string and expecting it to be convertible to a double. If there's any doubt, use TryParse.
If variable is a method argument, change the type to double. Make the caller responsible for providing the correct type. That way the compiler does the work for you.
string variable = "5.00";
double varDouble = (double)variable;
Above conversion is simply not allowed by language. Here is a list of explicit casts for numerical types: http://msdn.microsoft.com/en-us/library/yht2cx7b.aspx As you can see, even not every numerical type could be converted to another numerical type
Some more info about casting here
And how does this differ to Convert.ToDouble()?
When you cast a type, data structure is not changed. Well, in case of numerical values conversion it you may loose few bits or get few additional 0 bits. But you are still working with a number. You are just changing an amount of memory taken by that number. That is safe enough for compiler do everything needed.
But when you are trying to cast string to a number, you can't do that because it is not enough to change amount of memory taken by variable. For instance, 5.00 as a string is a sequence of "numbers":53(5) 46(.) 48(0) 48(0) - that is for ASCII, but string will contain something similar. If compiler will just take first N (4 for double? not sure) bytes from a string - that piece will contain completely different double number.
At the same time Convert.ToDouble() run special algorithm which will take each symbol of a string, figure out digit which it represents and make a double number for you, if string represents a number.
Languages like PHP will, roughly speaking, call Convert.ToDouble for you in background. But C#, like a statically typed language, will not do that for you. This allows you to be sure that any operation is type safe and you will not get something unexpected doing something like:
double d = (double)"zzzz"
Casting a string to a double like that is not allowed C# which is why you get an Exception, you need to have the string converted (MSDN doc that shows acceptable conversion paths). This is simply because a string isn't necessarily going to contain numeric data, but the various numeric types will (barring null values). A Convert will run a method that will check the string to see if it can be turned into a numeric value. If it can, then it will return that value. If it can't, it'll throw an exception.
To convert it, you have several options. You used the Convert method in your question, there's Parse which is largely similar to Convert, but you should also look at TryParse which would allow you to do:
string variable = "5.00";
double varDouble;
if (Double.TryParse(variable, out varDouble)) {
//Code that runs if the conversion succeeded.
} else {
//Code that runs if the conversion failed.
}
This avoids the possible exception should you try to Convert or Parse a non-numerical string.
The most important difference is that if type casting is used and the conversion fails
(say we are converting a very big float value to int ) no exception will be thrown and the minimum value an int can hold will be shown.
But in case of using Convert , an exception will be thrown for such scenarios.
Related
I have a CSV file of ID numbers that I need as an IEnumberable<int>. I was trying to get from A to B as simply as possible, and came up with the following idea:
Global.migrated = File.ReadAllText(Global.migrationList).Split(',').Cast<int>().ToList<int>();
When I run this, though, I'm told that the Cast is invalid. I also tried reading to a String list and casting to int:
List<string> myTemp = File.ReadAllText(Global.migrationList).Split(',').ToList<string>();
Global.migrated = myTemp.Cast<int>();
But this raises the following error:
Cannot implicitly convert type 'System.Collections.Generic.IEnumerable<int>' to 'System.Collections.List<int>.' An explicit conversion exists. Are you missing a cast?
I don't understand. The object I'm trying to cast isn't an IEnumerable<int> in this case. It should be a List<string>. I'm afraid I'm missing something important about how casting works.
You need to convert the object, not cast it.
File.ReadAllText(Global.migrationList).Split(',')
.Select(x=> Convert.ToInt32(x)).ToList();
A cast is different from a convert in as much as the string value is a string, and not a number as far as the CLR is concerned. If the object being cast was a float, decimal, double or any numerical type then cast would work fine. But as the object is a string the CLR has no way to cast the object. You can, however, convert a string to an integer which actually parses the object and returns a new object rather than just converting its CLR type.
While you may think of casting and converting as being very similar in practical uses, they are very different things to the CLR
You can't do Cast<int>() on an enumerable of strings for the same reason you can't do (int)"123" -- there is no such implicit or explicit conversion operator between string and int.1
Just use Select(), passing the string elements through int.Parse():
Global.migrated = File.ReadAllText(Global.migrationList)
.Split(',')
.Select(i => int.Parse(i))
.ToList();
1 Technically, if there could be such a user-defined operator then it wouldn't be used here anyway. Casts are resolved at compile-time, and generic types are substituted at runtime so user-defined conversion operators are not used when casting to or from generic types (except possibly when constraints are involved, as there is a certain amount of information that can be deduced at compile-time in that case). But I digress.
If I have this code, this will compile and work as it should:
class MyNumber // Just a class.
{
static public explicit operator MyNumber(byte b)
{
return new MyNumber();
}
}
Decimal d = new Decimal();
MyNumber c1 = (MyNumber)d;
Perhapse some people are a bit of a surprise, since there is no existing explicit cast from a decimal to MyNumber. But since there is a explicit cast from decimal to byte and there is also a explicit cast from a byte to MyNumber, the compiler is kind enough to insert that extra explicit cast for me.
In short: If the programmer uses an explicit cast, the compiler takes the freedom to search for other explicit cast to get the whole thing going.
So... I tried the same thing with my own classes. Instead of byte and decimal, I used MyByte and Mydecimal. The code looks like this:
class MyDecimal // Simulates a decimal.
{
static public explicit operator MyByte(MyDecimal a) // Just like in a decimal.
{
return new MyByte();
}
}
class MyByte // Simulates a byte.
{
}
class MyNumber // Just a class.
{
static public explicit operator MyNumber(MyByte b)
{
return new MyNumber();
}
}
MyDecimal d = new MyDecimal();
MyNumber c2 = (MyNumber)d; // <== Will not compile!
The last line will not compile. It gives the error: "Cannot convert type 'DoubleExplicitCasts.Program.MyDecimal' to 'DoubleExplicitCasts.Program.MyNumber'". Well... why not???
So my question is: Why do the explicit operators inside .NET system get a special treatment and my user explicit operators do not?
EDIT
I know this code is not functional and values are not transfered from one instance to another, but that is beside the point.
IMO, that would lead to "happy debugging" and really, really complicated and non-obvious code.
Just imagine 3 or more levels of such user-defined conversions, and how would you search for error, caused by conversion in the middle (e.g such conversion was introduced by mistake or not supposed to be used in that situation).
Thanks God such behaviour is not supported.
Well, trivially, because that's how it's defined by the C# standard.
From section 6.4.3:
Evaluation of a user-defined conversion never involves more than one user-defined or lifted conversion operator. In other words, a conversion from type S to type T will never first execute a user-defined conversion from S to X and then execute a user-defined conversion from X to T.
As to why they chose to limit the conversions in that way - that's a different matter. I'm going to propose two possible reasons:
It would allow the possibility of too many "surprising" conversions
It would make the compilation process too slow (possible combinational explosion)
but that's just conjecture on my part.
i want to know typecasting in c# .net, i have below lines of code.
int i=4
object o = i // This works properly without any typecasting becausing boxing takes place automatically
string s= i // This does not work, even when the string is also reference type?
string s=(string)i //This also does not work even if i try to typecast the int to string.
string s= Convert.ToString(i); // this works.
so i want to know why string s = i and string s = (string)i does not work and whats the difference in using (string)i, i.ToString(), and Convert.ToString(i).
When it comes to boxing and unboxing, types have explicit and implicit casting. So, in some circumstances, it is easy enough for the runtime to allow for implicit conversion between two supported types, say an Int32 to a Double. However, there is no implicit or explicit conversion between an integer and a string, because obviously, a string is not an integer (despite the fact that a string can contain characters for an integer).
string s = i; // attempt at implicit cast from Int32 to String, error
object o = i; // all types inherit from Object, so you may implicitly or explicitly cast from Int32 to Object.
s = (string)i; // attempt at explicit cast from Int32 to string, error
s = i.ToString(); // conversion
s = Convert.ToString(i); // conversion
That's where Convert comes to play. Convert contains support for attempting to convert known primitives (and types supporting IConvertable) to another. So, ToString or Convert.ToString would be the preferred methods (ToString and Convert.ToString are virtually synonymous, except that ToString gives you some formatting options).
Well, string and object - both of them are reference types. However, object is a root type for all .NET types.
When you use such syntax as (string)i, you are trying to use explicit conversion beetween types. But this conversion type requires string class to know about all possible argument types.
So we have .ToString() method, which can be overriden in any class, and its return value is used as a string represenation of any object.
string s = i and string s = (string)i does not work
because I is not a string, and type CASTING is a CAST of the type, not a conversion. It only works if i contains a string or a subclass of string (which is not possible for strings, but may be for other classes).
whats the difference in using (string)i, i.ToString(), and Convert.ToString(i).
(string) i: cast i to a string, must be assignable.
i.ToString(): calls the ToSstring method, which is defiend on System.object, thus available on ALL classes and structs - but returns no sensible content if not overwritten.
Convert.ToString(i): coonverts i to a string. THis includes calling a converter which likely just calls ToString on this rare case.
At the end, casting is not aconversion. for (string) i to work i HAS TO BE A STRING, while convert tries to MAKE it a string.
You can specify implicit and explicit conversions in .net, the reason that string s = i fails is that there is no built in cast operation for an integer to a string.
see this MSDN article on casting for further information
string s= i does not work because the types don't match, int won't go into a string.
string s=(string)i does not work because it cannot asume which type conversion is to be used (i.e which base)
something like s = ""+i would work on the other hand as it would asume base 10 conversion.
so i want to know why string s = i and string s = (string)i does not work
The short answer is that there is no implict (first example above) nor explicit (second example above) cast from int to string defined. Slightly longer answer; when authoring the struct Int32 in C# no casting behaviour was programmed to enable the developer to automagically cast from an int to a string
whats the difference in using (string)i, i.ToString(), and Convert.ToString(i)
Well, the first doesn;t work as you said, and as ive explained above. The second calls the ToString method on the struct Int32, which returns (as the name implies) a string representation of the object. It should be noted that this is a brand new string, not in any way related to the original value. The third example Convert.ToString will, under the hood, call whatever the most appropriate way to turn the parameter passed in to a string - most likely just calls the ToString method - so pretty much identical to example 2.
ToString() method is override by each referance which is vitual method in the object class. string calss override that method and provide string value out of this.
The default implementation of the ToString method returns the fully qualified name of the type of the Object, as the following example shows.
Object obj = new Object();
Console.WriteLine(obj.ToString());
// The example displays the following output:
// System.Object
this behavior is inherited by reference types that do not override the ToString method.
Typecasting in C# only works along the lines of class inheritance. Object is the root of all types in C# and therefore all values can be typecast to it.
string and int do not share the same branch of inheritance and so cannot be directly cast from one to the other.
Convert.ToString() is a method designed to convert an integer to a string - there's no typecasting going on, it's just executing a method designed to convert an integer to a string representation.
i.ToString() performs the equivalent functionality to Convert.ToString(), except that i.ToString() has overloads which allow greater flexibility on the representation of the number in string format.
One last note, exceptions to the typecasting rules can be included by the developer by using a public static explicit operator method which permits the developer to convert one value to another as they see fit.
First thing to note is that every class derives from object.
Casting int to object is using an Int32.
Casting string to object is using a String.
There is no implicit cast from an integer to a string because they are in different parts of the class hierarchy - one does not in any way relate to another. However because string is used so often for output object (and therefore all its children) have a ToString() method for convenience.
However Convert is written specifically to be able to convert from one type to another, for example Convert.ToBool(x) can parse "true" or "false" to boolean, and as you have shown it can convert an integer to a string - again this is really a convenience that probably just calls Int32.ToString() under the hood.
This question already has answers here:
When to use a Cast or Convert
(9 answers)
Closed 9 years ago.
A question cropped up at work today about how to convert an object into its specific type (an int), I said to cast it:
int i = (int)object;
a colleague said to use Convert.ToInt32().
int i = Convert.ToInt32(object)
What's the difference between Convert.ToInt32() and a direct object cast?
Not every object can be cast directly to int. For example, the following will not compile:
string s = "1";
int i = (int)s;
because string is not implicitly convertible to int.
However, this is legal:
string s = "1";
int i = Convert.ToInt32(s);
As a side note, both casting and Convert can throw exceptions if the input object cannot be converted. However, int.TryParse does not throw if it fails; rather, it returns false (but it only takes in a string, so you have to .ToString() your input object before using it):
object s = "1";
int i;
if(int.TryParse(s.ToString(), out i))
{
// i now has a value of 1
}
They are fundamentally different
Casting says that the object is an instance of the type being cast to, so cast it.
Convert says that there is a conversion between the types being converted.
So for example you can't cast a string to an int, but you can convert it. There is some grey area/overlap due to certain built in cast rules for primitive types, or explicit cast conversions you can add to your own types. But generally I wouldn't think of these two as the equivalent.
Given that there is no 'better' option, you should use the option that makes sense in the given context.
You can only cast when the original type has a cast defined for the new type. So casting from one numeric type to another (e.g. long to int) is normally possible but casting from non-numeric types to numeric types (e.g. string to int) normally is not possible. Convert provides many more methods to change these non-numeric types to numeric, so the reason to use it is you are less likely to get an error.
I tend to prefer Convert myself just because it provides a nice uniform interface to conversion. For example Convert.ToInt32("45") works but (int)"45", does not.
Convert will also report issues such as throwing an OverflowException. Casting can be dangerous as casting from say long to an int could yield a poor result and the runtime won't tell you.
I also like that Convert.ToX(object obj) exists, which lets you just fire things off to Convert and for the most part forget about it.
Convert.ToInt32 is basically the same as int.Parse
With one difference: if you use int.Parse(null) an exception is thrown, while Convert.ToInt32 returns 0
Casting on the other hand is a more complex operation and will only work if the value really is a boxed int or anohter (boxed/unboxed) value type that can be implicitly converted.
(boxing is an object representation of a value type)
Convert is a class that contains a series of static methods and is suposed to be used to convert base types, the supported types are Boolean, Char, SByte, Byte, Int16, Int32, Int64, UInt16, UInt32, UInt64, Single, Double, Decimal, DateTime and String.
The cast operator allows you to do the same thing but you can use it for other types as well, including the types you create. You also can define this operators in your classes, allowing you to convert from anything to anything.
So thats the difference, one is a method and the other one is an operator, I have not checked the guts of the operaror when converting and int to a string, but it might have the same logic as the methods in Convert.
If you know that the boxed instance is an int, you can safely use the (int) cast operator to unbox it. However, if it's convertible to an int (e.g. a float), using the cast operator will fail at runtime.
Check out the Convert class documentation for more details on the specific conversions it allows and disallows.
The difference is Convert.ToInt32(object value) will try to use IConvertible to convert the value to int where as direct cast will simply throw an exception if such cast is not valid.
The other overloads also try converting and not casting.
The following code throws an compile-time error like
Cannot convert type 'string' to 'int'
string name = Session["name1"].ToString();
int i = (int)name;
whereas the code below compiles and executes successfully:
string name = Session["name1"].ToString();
int i = Convert.ToInt32(name);
I would like to know:
Why does the the first code generate a compile-time error?
What's the difference between the 2 code snippets?
(int)foo is simply a cast to the Int32 (int in C#) type. This is built into the CLR and requires that foo be a numeric variable (e.g. float, long, etc.) In this sense, it is very similar to a cast in C.
Convert.ToInt32 is designed to be a general conversion function. It does a good deal more than casting; namely, it can convert from any primitive type to a int (most notably, parsing a string). You can see the full list of overloads for this method here on MSDN.
And as Stefan Steiger mentions in a comment:
Also, note that on a numerical level, (int) foo truncates foo (ifoo = Math.Floor(foo)), while Convert.ToInt32(foo) uses half to even rounding (rounds x.5 to the nearest EVEN integer, meaning ifoo = Math.Round(foo)). The result is thus not just implementation-wise, but also numerically not the same.
(this line relates to a question that was merged) You should never use (int)someString - that will never work (and the compiler won't let you).
However, int int.Parse(string) and bool int.TryParse(string, out int) (and their various overloads) are fair game.
Personally, I mainly only use Convert when I'm dealing with reflection, so for me the choice is Parse and TryParse. The first is when I expect the value to be a valid integer, and want it to throw an exception otherwise. The second is when I want to check if it is a valid integer - I can then decide what to do when it is/isn't.
To quote from this Eric Lippert article:
Cast means two contradictory things: "check to see if this object really is of this type, throw if it is not" and "this object is not of the given type; find me an equivalent value that belongs to the given type".
So what you were trying to do in 1.) is assert that yes a String is an Int. But that assertion fails since String is not an int.
The reason 2.) succeeds is because Convert.ToInt32() parses the string and returns an int. It can still fail, for example:
Convert.ToInt32("Hello");
Would result in an Argument exception.
To sum up, converting from a String to an Int is a framework concern, not something implicit in the .Net type system.
A string cannot be cast to an int through explicit casting. It must be converted using int.Parse.
Convert.ToInt32 basically wraps this method:
public static int ToInt32(string value)
{
if (value == null)
{
return 0;
}
return int.Parse(value, CultureInfo.CurrentCulture);
}
You're talking about a C# casting operation vs .NET Conversion utilities
C# Language-level casting uses parenthesis - e.g. (int) - and conversion support for it is limited, relying on implicit compatibility between the types, or explicitly defined instructions by the developer via conversion operators.
Many conversion methods exist in the .NET Framework, e.g. System.Convert, to allow conversion between same or disparate data types.
(Casting) syntax works on numeric data types, and also on "compatible" data types. Compatible means data types for which there is a relationship established through inheritance (i.e. base/derived classes) or through implementation (i.e. interfaces).
Casting can also work between disparate data types that have conversion operators defined.
The System.Convert class on the other hand is one of many available mechanisms to convert things in the general sense; it contains logic to convert between disparate, known, data types that can be logically changed from one form into another.
Conversion even covers some of the same ground as casting by allowing conversion between similar data types.
Remember that the C# language has its own way of doing some things.
And the underlying .NET Framework has its own way of doing things, apart from any programming language.
(Sometimes they overlap in their intentions.)
Think of casting as a C# language-level feature that is more limited in nature, and conversion via the System.Convert class as one of many available mechanisms in the .NET framework to convert values between different kinds.
There is not a default cast from string to int in .NET. You can use int.Parse() or int.TryParse() to do this. Or, as you have done, you can use Convert.ToInt32().
However, in your example, why do a ToString() and then convert it back to an int at all? You could simply store the int in Session and retrieve it as follows:
int i = Session["name1"];
Just a brief extra: in different circumstances (e.g. if you're converting a double, &c to an Int32) you might also want to worry about rounding when choosing between these two. Convert.Int32 will use banker's rounding (MSDN); (int) will just truncate to an integer.
1) C# is type safe language and doesn't allow you to assign string to number
2) second case parses the string to new variable.
In your case if the Session is ASP.NET session than you don't have to store string there and convert it back when retrieving
int iVal = 5;
Session[Name1] = 5;
int iVal1 = (int)Session[Name1];
This is already discussed but I want to share a dotnetfiddle.
If you are dealing with arithmetic operations and using float, decimal, double and so on, you should better use Convert.ToInt32().
using System;
public class Program
{
public static void Main()
{
double cost = 49.501;
Console.WriteLine(Convert.ToInt32(cost));
Console.WriteLine((int)cost);
}
}
Output
50
49
https://dotnetfiddle.net/m3ddDQ
Convert.ToInt32
return int.Parse(value, CultureInfo.CurrentCulture);
but (int) is type cast, so (int)"2" will not work since you cannot cast string to int. but you can parse it like Convert.ToInt32 do
The difference is that the first snippet is a cast and the second is a convert. Although, I think perhaps the compiler error is providing more confusion here because of the wording. Perhaps it would be better if it said "Cannot cast type 'string' to 'int'.
This is old, but another difference is that (int) doesn't round out the numbers in case you have a double ej: 5.7 the ouput using (int) will be 5 and if you use Convert.ToInt() the number will be round out to 6.