Develop Reference

Is there any way to create a function that can change the data type of a variable?

I 'm new to C#. Is there any way to create a function that can change the datatype of a variable to an another datatype and return the changed value.
I don't want to use the built-in Convert class.
For example :
Let's assume that ChangeDataType is the name of the function. It should also be possible to do the same thing with all datatypes.
int a = 5;
float b = ChangeDataType(a, "float"); // 5.0
Thanks.

Please note that you cannot change data type of already declared variable. But you can create new variable of desired type and then typecast old variable into new one. If this type casting fails, then invalidcastexception is thrown.
Below are different kinds of typecasting options:
1. Implicit Type casting
In this you don't need to use any syntax.
For ex:
int i = 10;
float a = i;
2. Explicit Type casting
You need to specify the type in which you want to convert to. For ex:
class Test
{
static void Main()
{
double x = 1234.7;
int a;
// Cast double to int.
a = (int)x;
System.Console.WriteLine(a);
}
}
// Output: 1234
3. User Defined Casts
Using implict and explicit keywords in c#.
Please refer
4. Helper Classes
There are many classes which provides method to convert data types.
One of the important class is - Convert.
This class provides a lot of methods. Convert.ToString, Convert.ToInt32, etc.
Another example is TryParse methods in int, long, double, DateTime, etc classes. Please refer

Is there a technical reason for requiring the "out" and "ref" keywords at the caller?

When calling a method with a ref or out parameter, you have to specify the appropriate keyword when you call the method. I understand that from a style and code quality standpoint (as explained here for example), but I'm curious whether there is also a technical need for the keywords to be specified in the caller.
For example:
static void Main()
{
int y = 0;
Increment(ref y); // Is there any technical reason to include ref here?
}
static void Increment(ref int x)
{
x++;
}

The only technical reason I could think of is overload resolution: you could have
static void Increment(ref int x)
and also
static void Increment(int x)
This is allowed; without ref in the call, the compiler wouldn't be able to tell them apart.

If you're asking whether the language could have been designed so that those aren't needed at the call site, the answer is yes. There is no particular reason they could not have been left out. The compiler has all the information it needs from the metadata, so it could make the proper transformation.
That said, doing so would have made it impossible to have these two overloads:
public void DoSomething(int x);
public void DoSomething(ref int x);
The compiler wouldn't be able to disambiguate that.
Although the ref and out could have been made optional, in which case those overloads would be allowed. And the compiler could either take the default (i.e. the non-ref), or issue an ambiguity error and make you specify which one you really wanted.
All that said, I like having to specify ref and out at the call site. It tells me that the parameter could potentially be modified. Having worked in Pascal for many years, where a var parameter is passed the same way that a value parameter is passed (the syntax at the call site is the same), I much prefer the specificity of C# in that regard.

Another reason to require the modifier is to make changing a parameter to a ref or out a breaking change. If the ref/out could be inferred, then an evil programmer changing a parameter from by-value to by-reference would not be detected by clients compiling against the new signature. If a client called the method
public int Increment(int x)
{
return x + 1;
}
by using
int result = Increment(x);
Suppose an evil developer decided to change the implementation to instead change the value passed by reference and return an error code if, say, the increment resulted in an overflow:
public int Increment(ref int x)
{
x = x + 1;
if(x == int.MinValue) // overflow
return -1;
else
return 0;
}
Then a client building against the signature would not receive a compile error, but it would almost certainly break the calling app.

The compiler needs to know the method parameters it is interpreting when it is building IL.
One reason is having overloads like:
public void (ref int x) {}
public void (int x) {}
Another reason is out will explicitly allow you to use pass-by-value parameter use the interpreted value outside the method. ref will give the pointer to the parameter thereby pointing any new value from the method to the same memory location

Difference between Casting, Parsing and Converting [duplicate]

This question already has answers here:
Is casting the same thing as converting?
(11 answers)
Closed 9 years ago.
I have been working on some code for a while. And I had a question: What's the difference among casting, parsing and converting? And when we can use them?

Casting is when you take a variable of one type and change it to a different type. You can only do that in some cases, like so:
string str = "Hello";
object o = str;
string str2 = (string)o; // <-- This is casting
Casting does not change the variable's value - the value remains of the same type (the string "Hello").
Converting is when you take a value from one type and convert it to a different type:
double d = 5.5;
int i = (int)d; // <---- d was converted to an integer
Note that in this case, the conversion was done in the form of casting.
Parsing is taking a string and converting it to a different type by understanding its content. For instance, converting the string "123" to the number 123, or the string "Saturday, September 22nd" to a DateTime.

Casting: Telling the compiler that an object is really something else without changing it (though some data loss may be incurred).
object obj_s= "12345";
string str_i = (string) obj; // "12345" as string, explicit
int small = 12345;
long big = 0;
big = small; // 12345 as long, implicit
Parsing: Telling the program to interpret (on runtime) a string.
string int_s = "12345";
int i = int.Parse(int_s); // 12345 as int
Converting: Telling the program to use built in methods to try to change type for what may be not simply interchangeable.
double dub = 123.45;
int i = System.Convert.ToInt32(dub); // 123 as int

These are three terms each with specific uses:
casting - changing one type to another. In order to do this, the
types must be compatible: int -> object; IList<T> -> IEnumerable<T>
parsing - typically refers to reading strings and extracting useful parts
converting - similar to casting, but typically a conversion would involve changing one type to an otherwise non-compatible type. An example of that would be converting objects to strings.
A cast from one type to another requires some form of compatibility, usually via inheritance or implementation of an interface. Casting can be implicit or explicit:
class Foo : IFoo {
// implementations
}
// implicit cast
public IFoo GetFoo() {
return Foo;
}
// explicit cast
public IFoo GetFoo() {
return Foo as IFoo;
}
There are quite a few ways to parse. We read about XML parsing; some types have Parse and TryParse methods; and then there are times we need to parse strings or other types to extract the 'stuff we care about'.
int.Parse("3") // returns an integer value of 3
int.TryParse("foo", out intVal) // return true if the string could be parsed; otherwise false
Converting may entail changing one type into another incompatible one. This could involve some parsing as well. Conversion examples would usually be, IMO, very much tied to specific contexts.

casting
(casting to work the types need to be compatible)
Converting between data types can be done explicitly using a cast
static void _Casting()
{
int i = 10;
float f = 0;
f = i; // An implicit conversion, no data will be lost.
f = 0.5F;
i = (int)f; // An explicit conversion. Information will be lost.
}
parsing (Parsing is conversion between different types:)
converts one type to another type can be called as parsing uisng int.parse
int num = int.Parse("500");
traversing through data items like XML can be also called as parsing
When user-defined conversions get involved, this usually entails returning a different object/value. user-defined conversions usually exist between value types rather than reference types, so this is rarely an issue.
converting
Using the Convert-class actually just helps you parse it
for more please refer http://msdn.microsoft.com/en-us/library/ms228360%28VS.80%29.aspx

This question is actually pretty complicated...
Normally, a cast just tells the runtime to change one type to another. These have to be types that are compatible. For example an int can always be represented as a long so it is OK to cast it to a long. Some casts have side-effects. For example, a float will drop its precision if it is cast to an int. So (int)1.5f will result in int value 1. Casts are usually the fastest way to change the type, because it is a single IL operator. For example, the code:
public void CastExample()
{
int i = 7;
long l = (long)i;
}
Performs the cast by running the IL code:
conv.i8 //convert to 8-byte integer (a.k.a. Int64, a.k.a. long).
A parse is some function that takes in once type and returns another. It is an actual code function, not just an IL operator. This usually takes longer to run, because it runs multiple lines of code.
For example, this code:
public void ParseExample()
{
string s = "7";
long l = long.Parse(s);
}
Runs the IL code:
call int64 [mscorlib]System.Int64::Parse(string)
In other words it calls an actual method. Internally, the Int64 type provides that method:
public static long Parse(String s) {
return Number.ParseInt64(s, NumberStyles.Integer, NumberFormatInfo.CurrentInfo);
}
And Number.Parse:
[System.Security.SecuritySafeCritical] // auto-generated
internal unsafe static Int64 ParseInt64(String value, NumberStyles options, NumberFormatInfo numfmt) {
Byte * numberBufferBytes = stackalloc Byte[NumberBuffer.NumberBufferBytes];
NumberBuffer number = new NumberBuffer(numberBufferBytes);
Int64 i = 0;
StringToNumber(value, options, ref number, numfmt, false);
if ((options & NumberStyles.AllowHexSpecifier) != 0) {
if (!HexNumberToInt64(ref number, ref i)) {
throw new OverflowException(Environment.GetResourceString("Overflow_Int64"));
}
}
else {
if (!NumberToInt64(ref number, ref i)) {
throw new OverflowException(Environment.GetResourceString("Overflow_Int64"));
}
}
return i;
}
And so on... so you can see it is actually doing a lot of code.
Now where things get more complicated is that although a cast is usually the fastest, classes can override the implicit and explicit cast operators. For example, if I write the class:
public class CastableClass
{
public int IntValue { get; set; }
public static explicit operator int(CastableClass castable)
{
return castable.IntValue;
}
}
I have overridden the explicit cast operator for int, so I can now do:
public void OverridedCastExample()
{
CastableClass cc = new CastableClass {IntValue = 7};
int i = (int)cc;
}
Which looks like a normal cast, but in actuality it calls my method that I defined on my class. The IL code is:
call int32 UnitTestProject1.CastableClass::op_Explicit(class UnitTestProject1.CastableClass)
So anyway, you typically want to cast whenever you can. Then parse if you can't.

Casting: or Parsing
A cast explicitly invokes the conversion operator from one type to another.
Casting variables is not simple. A complicated set of rules resolves casts. In some cases data is lost and the cast cannot be reversed. In others an exception is provoked in the execution engine.
int.Parse is a simplest method but it throws exceptions on invalid input.
TryParse
int.TryParse is one of the most useful methods for parsing integers in the C# language. This method works the same way as int.Parse.
int.TryParse has try and catch structure inside. So, it does not throw exceptions
Convert:
Converts a base data type to another base data type.
Convert.ToInt32, along with its siblings Convert.ToInt16 and Convert.ToInt64, is actually a static wrapper method for the int.Parse method.
Using TryParse instead of Convert or Cast is recommended by many programmers.
source:www.dotnetperls.com

Different people use it to mean different things. It need not be true outside .net world, but here is what I have understood in .net context reading Eric Lippert's blogs:
All transformations of types from one form to another can be called conversion. One way of categorizing may be
implicit -
a. representation changing (also called coercion)
int i = 0;
double d = i;
object o = i; // (specifically called boxing conversion)
IConvertible o = i; // (specifically called boxing conversion)
Requires implicit conversion operator, conversion always succeeds (implicit conversion operator should never throw), changes the referential identity of the object being converted.
b. representation preserving (also called implicit reference conversion)
string s = "";
object o = s;
IList<string> l = new List<string>();
Only valid for reference types, never changes the referential identity of the object being converted, conversion always succeeds, guaranteed at compile time, no runtime checks.
explicit (also called casting) -
a. representation changing
int i = 0;
enum e = (enum)i;
object o = i;
i = (int)o; // (specifically called unboxing conversion)
Requires explicit conversion operator, changes the referential identity of the object being converted, conversion may or may not succeed, does runtime check for compatibility.
b. representation preserving (also called explicit reference conversion)
object o = "";
string s = (string)o;
Only valid for reference types, never changes the referential identity of the object being converted, conversion may or may not succeed, does runtime check for compatibility.
While conversions are language level constructs, Parse is a vastly different thing in the sense it's framework level, or in other words they are custom methods written to get an output from an input, like int.Parse which takes in a string and returns an int.

Questions on delegate functions in C#?

I'm learning about C# and one of the areas that interested me were delegate functions. The following code uses them to apply a function to each number in a range [start, limit[ before it is summed. This is a fairly simple example for clarity.
// function passing a delegate function
public override void solveProblem() {
int squareOfSum = (int) Math.Pow(Library.Math.sumRange(1, 101), 2);
int sumOfSquares = Library.Math.sumRange(1, 101, new Func<double, double, double>(Math.Pow), 2);
this.solution = (squareOfSum - sumOfSquares).ToString();
}
// function that accepts / uses delegate function
static public int sumRange(int start, int limit, Delegate operation, params object[] args) {
int sum = 0;
for (int current = start; current < limit; current++) {
// add the current number in the range as an arguement
object[] newArgs = new object[args.Length + 1];
newArgs[0] = current;
args.CopyTo(newArgs, 1);
// sum the result of the operation (delegate function)
sum += Convert.ToInt32(operation.DynamicInvoke(newArgs));
}
return sum;
}
The specific questions I have are:
Is it possible to use dynamic delegate functions (that accept a variable length list of parameters with unkown types) but force the delegate function to return a specific type? With non-dynamic delegate functions you set a return type, but also have to set the number of parameters and their types.
How much slower is using DynamicInvoke than using a non-dynamic delegate function?
What is the best way to handle parameters than what I currently do (which is accept a list of other parameters and prepend any parameters the function that uses the delegate needs to add in)?
Do I need to declare 'new Func(Math.Pow)' to pass in the power function, or is there a way to just pass Math.Pow (and have the return type and parameters be passed implicitly)?
I've looked at the C# docs and this StackOverflow question to learn how to use delegate functions, I just want to learn more about them.
Thanks!
jtfairbank

Is it possible to use dynamic delegate functions (that accept a
variable length list of parameters with unkown types) but force the
delegate function to return a specific type? With non-dynamic delegate
functions you set a return type, but also have to set the number of
parameters and their types.
You don't "force" the function to return something. The function returns something or it doesn't return something. The function "forces" you to accept something :-) (or to ignore it)
You can call a dynamic delegate through the DynamicInvoke and then cast the return value to what you know your delegate returns (or you keep it as an object). I say "what you know your delegate returns" but the reality is a little more complex: for Value Types you have to cast the return value to precisely the type used as return value or you'll get InvalidCastException. For reference types you can use an interface or a base class of the object returned (with some exceptions for Nullable types)
How much slower is using DynamicInvoke than using a non-dynamic delegate function?
I've tested a void Do() method (the most simple method possible, with no boxing for parameters) and the time difference was demential. Let's say 400x :-) On http://ideone.com/f34cj it's between 70x and 150x.
Do I need to declare 'new Func(Math.Pow)' to pass in the power function, or is there a way to just pass Math.Pow (and have the return type and parameters be passed implicitly)?
Creating a new Func/Action delegate is the right path.
In general the right solution is not what you are doing. The right solution is do as LINQ does. For example:
int pow = 2;
Func<int, int> myFunc = p => (int)Math.Pow(p, pow);
var listOfNumbers = Enumerable.Range(1, 100);
var result = listOfNumbers.Sum(p => myFunc(p));
Now, you have a delegate (myFunc) that takes a number and returns the square of that number (and note that through "closures" it closes around pow) (if you don't know what a closure is, try putting that word in google with the words lambda function). A list of numbers as an IEnumerable<int> and you do the sum of these numbers "converted" by myFunc.

Read on LINQ - usage of IEnumerable produces much more compact code.
I.e. combination of Enumrable.Range ( http://msdn.microsoft.com/en-us/library/system.linq.enumerable.range.aspx ) and Enumerable.Aggregate ( http://msdn.microsoft.com/en-us/library/bb548651.aspx ) is exactly what you trying to achieve:
var sum = Enumerable.Range(start,limit).Aggregate((s, cur)=> s+cur);
var sumSq = Enumerable.Range(start,limit).Aggregate((s, cur)=> s+ cur * cur);

How to check assignability of types at runtime in C#?

The Type class has a method IsAssignableFrom() that almost works. Unfortunately it only returns true if the two types are the same or the first is in the hierarchy of the second. It says that decimal is not assignable from int, but I'd like a method that would indicate that decimals are assignable from ints, but ints are not always assignable from decimals. The compiler knows this but I need to figure this out at runtime.
Here's a test for an extension method.
[Test]
public void DecimalsShouldReallyBeAssignableFromInts()
{
Assert.IsTrue(typeof(decimal).IsReallyAssignableFrom(typeof(int)));
Assert.IsFalse(typeof(int).IsReallyAssignableFrom(typeof(decimal)));
}
Is there a way to implement IsReallyAssignableFrom() that would work like IsAssignableFrom() but also passes the test case above?
Thanks!
Edit:
This is basically the way it would be used. This example does not compile for me, so I had to set Number to be 0 (instead of 0.0M).
[AttributeUsage(AttributeTargets.Property | AttributeTargets.Parameter)]
public class MyAttribute : Attribute
{
public object Default { get; set; }
}
public class MyClass
{
public MyClass([MyAttribute(Default= 0.0M)] decimal number)
{
Console.WriteLine(number);
}
}
I get this error:
Error 4 An attribute argument must be a constant expression, typeof expression or array creation expression of an attribute parameter type

There are actually three ways that a type can be “assignable” to another in the sense that you are looking for.
Class hierarchy, interface implementation, covariance and contravariance. This is what .IsAssignableFrom already checks for. (This also includes permissible boxing operations, e.g. int to object or DateTime to ValueType.)
User-defined implicit conversions. This is what all the other answers are referring to. You can retrieve these via Reflection, for example the implicit conversion from int to decimal is a static method that looks like this:
System.Decimal op_Implicit(Int32)
You only need to check the two relevant types (in this case, Int32 and Decimal); if the conversion is not in those, then it doesn’t exist.
Built-in implicit conversions which are defined in the C# language specification. Unfortunately Reflection doesn’t show these. You will have to find them in the specification and copy the assignability rules into your code manually. This includes numeric conversions, e.g. int to long as well as float to double, pointer conversions, nullable conversions (int to int?), and lifted conversions.
Furthermore, a user-defined implicit conversion can be chained with a built-in implicit conversion. For example, if a user-defined implicit conversion exists from int to some type T, then it also doubles as a conversion from short to T. Similarly, T to short doubles as T to int.

This one almost works... it's using Linq expressions:
public static bool IsReallyAssignableFrom(this Type type, Type otherType)
{
if (type.IsAssignableFrom(otherType))
return true;
try
{
var v = Expression.Variable(otherType);
var expr = Expression.Convert(v, type);
return expr.Method == null || expr.Method.Name == "op_Implicit";
}
catch(InvalidOperationException ex)
{
return false;
}
}
The only case that doesn't work is for built-in conversions for primitive types: it incorrectly returns true for conversions that should be explicit (e.g. int to short). I guess you could handle those cases manually, as there is a finite (and rather small) number of them.
I don't really like having to catch an exception to detect invalid conversions, but I don't see any other simple way to do it...

Timwi's answer is really complete, but I feel there's an even simpler way that would get you the same semantics (check "real" assignability), without actually defining yourself what this is.
You can just try the assignment in question and look for an InvalidCastException (I know it's obvious). This way you avoid the hassle of checking the three possible meanings of assignability as Timwi mentioned. Here's a sample using xUnit:
[Fact]
public void DecimalsShouldReallyBeAssignableFromInts()
{
var d = default(decimal);
var i = default(i);
Assert.Throws<InvalidCastException)( () => (int)d);
Assert.DoesNotThrow( () => (decimal)i);
}

What you are looking for is if there's an implicit cast from the one type to the other. I would think that's doable by reflection, though it might be tricky because the implicit cast should be defined as an operator overload which is a static method and I think it could be defined in any class, not just the one that can be implicitly converted.

In order to find out if one type can be assigned to another, you have to look for implicit conversions from one to the other. You can do this with reflection.
As Timwi said, you will also have to know some built-in rules, but those can be hard-coded.

It actually happens to be the case that the decimal type is not "assignable" to the int type, and vice versa. Problems occur when boxing/unboxing gets involved.
Take the example below:
int p = 0;
decimal d = 0m;
object o = d;
object x = p;
// ok
int a = (int)d;
// invalid cast exception
int i = (int)o;
// invalid cast exception
decimal y = (decimal)p;
// compile error
int j = d;
This code looks like it should work, but the type cast from object produces an invalid cast exception, and the last line generates a compile-time error.
The reason the assignment to a works is because the decimal class has an explicit override on the type cast operator to int. There does not exist an implicit type cast operator from decimal to int.
Edit: There does not exist even the implicit operator in reverse. Int32 implements IConvertible, and that is how it converts to decimal
End Edit
In other words, the types are not assignable, but convertible.
You could scan assemblies for explicit type cast operators and IConvertible interfaces, but I get the impression that would not serve you as well as programming for the specific few cases you know you will encounter.
Good luck!