I just started learning C# today, and I am trying to make a generic method which can operate on different enums. I got some code that I found in another question on paper, but the compiler keeps complaining. I was wondering if someone could give me a hand. Here is what I have so far:
static void ReadMenuInput<T>(out T menuInput)
{
while (true)
{
if (enum<T>.TryParse(Console.ReadLine(), out menuInput) && menuInput < sizeof(T))
{
break;
}
Console.WriteLine("Please enter a valid input.");
}
}
Thank you for your help!
There are a couple of different issues with that particular code snippet, some of them easier to deal with than others. A few of them are simply showing your lack of experience:
enum and Enum are not interchangable; one is a class name and one is a C# keyword. In some cases (say, string and String) the keyword is just an alias for the type, but enum is not a type name, it is used to define type names. To call class methods you need to use Enum.
You are trying to call the generic TryParse<> method with the wrong syntax; it should be Enum.TryParse<T>.
Enumerations and integers are not the same type, and you cannot just compare them. They are, however, convertible to one another via an explicit typecast. Since sizeof returns an int, you need such a typecast (but see below).
The more complex issues with your code sample:
sizeof(enum) doesn't do quite what you expect, I think; it returns the size in bytes of the enum, which is typically going to be 4. You probably want the IsDefined method, which lets you know if a particular integer value is defined in an enumerated type
As the compiler will tell you, you can only use generic types in this context that are non-nullable. The way to define this is with a where T: struct constraint on your generic type. Note that, despite its name, this doesn't force your type to be a structure; it simply forces it to be a value type.
There is no way for you specify a constraint on the generic type that it must be an enumerated type; if you pass some other value type into the method, it will throw an exception at run-time. It's up to you to handle this case properly.
Here's a working (as in -- it compiles -- I haven't actually tested it) version of the code snippet you want. However, I will point out that every one of the problems in your original code would be worked out just by reading and understanding the error messages; this is one of the most important skills you should get good at as a C# developer.
static void ReadMenuInput<T>(out T menuInput) where T : struct
{
while (true)
{
if (Enum.TryParse<T>(Console.ReadLine(), out menuInput)
&& Enum.IsDefined(typeof(T), menuInput))
{
break;
}
Console.WriteLine("Please enter a valid input.");
}
}
Related
Why is this a compile time error?
public TCastTo CastMe<TSource, TCastTo>(TSource i)
{
return (TCastTo)i;
}
Error:
Cannot convert type 'TSource' to 'TCastTo'
And why is this a runtime error?
public TCastTo CastMe<TSource, TCastTo>(TSource i)
{
return (TCastTo)(object)i;
}
int a = 4;
long b = CastMe<int, long>(a); // InvalidCastException
// this contrived example works
int aa = 4;
int bb = CastMe<int, int>(aa);
// this also works, the problem is limited to value types
string s = "foo";
object o = CastMe<string, object>(s);
I've searched SO and the internet for an answer to this and found lots of explanations on similar generic related casting issues, but I can't find anything on this particular simple case.
Why is this a compile time error?
The problem is that every possible combination of value types has different rules for what a cast means. Casting a 64 bit double to a 16 bit int is completely different code from casting a decimal to a float, and so on. The number of possibilities is enormous. So think like the compiler. What code is the compiler supposed to generate for your program?
The compiler would have to generate code that starts the compiler again at runtime, does a fresh analysis of the types, and dynamically emits the appropriate code.
That seems like perhaps more work and less performance than you expected to get with generics, so we simply outlaw it. If what you really want is for the compiler to start up again and do an analysis of the types, use "dynamic" in C# 4; that's what it does.
And why is this a runtime error?
Same reason.
A boxed int may only be unboxed to int (or int?), for the same reason as above; if the CLR tried to do every possible conversion from a boxed value type to every other possible value type then essentially it has to run a compiler again at runtime. That would be unexpectedly slow.
So why is it not an error for reference types?
Because every reference type conversion is the same as every other reference type conversion: you interrogate the object to see if it is derived from or identical to the desired type. If it's not, you throw an exception (if doing a cast) or result in null/false (if using the "as/is" operators). The rules are consistent for reference types in a way that they are not for value types. Remember reference types know their own type. Value types do not; with value types, the variable doing the storage is the only thing that knows the type semantics that apply to those bits. Value types contain their values and no additional information. Reference types contain their values plus lots of extra data.
For more information see my article on the subject:
http://ericlippert.com/2009/03/03/representation-and-identity/
C# uses one cast syntax for multiple different underlying operations:
upcast
downcast
boxing
unboxing
numeric conversion
user-defined conversion
In generic context, the compiler has no way of knowing which of those is correct, and they all generate different MSIL, so it bails out.
By writing return (TCastTo)(object)i; instead, you force the compiler to do an upcast to object, followed by a downcast to TCastTo. The compiler will generate code, but if that wasn't the right way to convert the types in question, you'll get a runtime error.
Code Sample:
public static class DefaultConverter<TInput, TOutput>
{
private static Converter<TInput, TOutput> cached;
static DefaultConverter()
{
ParameterExpression p = Expression.Parameter(typeof(TSource));
cached = Expression.Lambda<Converter<TSource, TCastTo>(Expression.Convert(p, typeof(TCastTo), p).Compile();
}
public static Converter<TInput, TOutput> Instance { return cached; }
}
public static class DefaultConverter<TOutput>
{
public static TOutput ConvertBen<TInput>(TInput from) { return DefaultConverter<TInput, TOutput>.Instance.Invoke(from); }
public static TOutput ConvertEric(dynamic from) { return from; }
}
Eric's way sure is shorter, but I think mine should be faster.
The compile error is caused because TSource cannot be implicitly cast to TCastTo. The two types may share a branch on their inheritance tree, but there is no guarantee. If you wanted to call only types that did share an ancestor, you should modify the CastMe() signature to use the ancestor type instead of generics.
The runtime error example avoids the error in your first example by first casting the TSource i to an object, something all objects in C# derive from. While the compiler doesn't complain (because object -> something that derives from it, could be valid), the behaviour of casting via (Type)variable syntax will throw if the cast is invalid. (The same problem that the compiler prevented from happening in example 1).
Another solution, which does something similar to what you're looking for...
public static T2 CastTo<T, T2>(T input, Func<T, T2> convert)
{
return convert(input);
}
You'd call it like this.
int a = 314;
long b = CastTo(a, i=>(long)i);
Hopefully this helps.
Can someone explain to me why the compiler does not check the return type of a function if a dynamic variable is used as an argument to a method call?
class Program
{
static void Main(string[] args)
{
// int a = GetAString(1); // Compiler error CS0029 Cannot impilicitly convert type 'string' to 'int'
dynamic x = 1;
int b = GetAString(x); // No compiler error -> Runtime Binder Exception
// int c = (string)GetAString(x); // Compiler error CS0029 Cannot impilicitly convert type 'string' to 'int'
}
static string GetAString(int uselessInt)
{
return "abc";
}
}
By using dynamic the compiler will generate a call site anywhere you use a dynamic parameter. This call site will attempt to resolve the method at runtime, and if it cannot find a matching method will raise an exception.
In your example the call site examines x and sees that it is an int. It then looks for any methods called GetAString that take an int and finds your method and generates code to make the call.
Next, it will generate code to attempt to assign the return value to b. All of this is still done at runtime as the use of the dynamic variable has made the entire expression require runtime evaluation. The call site will see if it can generate code to assign a string to an int, and as it cannot it will raise an exception.
As an aside, your example doesn't make a lot of sense as you seem to want to assign a string to an int Your GetAsString method is even returning a non-numeric value so it's never going to assign to an int. If you write:
dynamic x = 1;
string b = GetAsString(x);
Then everything should work.
In the general case, the candidates aren't necessarily as straightforward as yours. For example, consider these two methods:
string M(string a) => a;
char[] M(char[] a) => a;
What should this code suggest as the type of the last variable?
dynamic d = SomeExpression();
var s = M(d);
At this point, the designers of C# would have to make a choice:
Assert that the return value of a method called with dynamic arguments is also dynamic itself.
Select a type that can be assigned from all methods of the group (e.g. IEnumerable<char>).
The latter option is essentially what you're describing in your question. The C# designers went with the former option. Possible reasons for that design decision could be:
Maybe they thought that if you opt in to dynamic in an expression, then it's more likely than not that you'll want to keep using dynamic on any dependent expressions, until you explicitly opt out of it again.
Maybe they didn't introduce dynamic to enable multiple dispatch, so they didn't want to encourage it further by including provisions for static typing.
Maybe they thought that including those provisions would bloat the specification or make the language harder to understand.
Maybe the former option is simpler to implement (assuming you already have the rest of dynamic implemented) and they decided the other option wasn't worth more time or effort.
Maybe it's just not that straightforward to implement in C#. Value types could require boxing to match the common supertype, which complicates things. Raw pointer types are out of the unified hierarchy altogether.
A junior co-worker of mine managed to write very scary, scary code.
printJob.Type = item[LocalFunctions.GetName(new { printJob.Type })].ToString();
public static string GetName<T>(T item) where T : class
{
try
{
return typeof(T).GetProperties()[0].Name;
}
catch (Exception ex)
{
return null;
}
}
What is you gues what will GetName will output? It will output "Type"!
I just don't get how this is possible. My first thought is that MS will create an anonymous type with property that has the same name as the property from which the value came from (compiler magic?). As this cannot possibly be a supported feature, I advised my junior co-worker to not use things he cannot understand.
But that leaves the question open: How is this possible?
Anonymous types infer property names unless they are specified:
If you do not specify member names in the anonymous type, the compiler
gives the anonymous type members the same name as the property being
used to initialize them.
http://msdn.microsoft.com/en-us/library/bb397696.aspx
The compiler then infers the type for the generic at compile time - so typeof(T) works. It is fully supported, even if the code is fragile. What happens when someone refactors the name of the property?
I'd also say it's inadvisable to advise people on topics you don't have an answer to yourself - this is the source of many a www.thedailywtf.com article ;-)
Personally I'd still remove this in favour of more robust code, instead of assuming the property name is always going to be the same.
That's what the compiler (not MS) does when creating anonymous types. It uses The type, name and order of the supplied parameters to construct a new type. This is fully supported and intended to be that way, so there's no reason not to use it.
The compiler has all the information available to do this. It sees what name and type the properties you used to initialize it have (such as printJob.Type) and can use that information to generate the anonymous type for you.
See here for more information:
http://msdn.microsoft.com/en-us/library/bb397696.aspx
Consider the following code
enum HorizontalAlignment { Left, Middle, Right };
enum VerticleAlignment { Top, Middle, Bottom };
function OutputEnumValues (Type enumType)
{
foreach (string name in Enum.GetNames(typeof(enumType)))
{
Console.WriteLine(name);
}
}
Which can be called like
OutputEnumValues (typeof(HorizontalAlignment));
OutputEnumValues (typeof(VerticleAlignment ));
But I could inadvertantly call, for example
OutputEnumValues (typeof(int));
And this will compile but fail at runtime at Enum.GetNames()
Any way of writing the method signature to catch this sort of problem at compile time - i.e. only accepting enum types in OutputEnumValues?
Every enum type is just an integer (which can be 8-, 16-, 32- or 64-bit and signed or unsigned). You can cast the integer 0 to any enum type, and it will become a value that is statically typed to the enum.
Furthermore, you can have a parameter of type Enum to ensure that only enum values are passed in, without knowing the actual enum type.
Thus, my solution looks like this:
public static void OutputEnumValues(Enum example)
{
foreach (string name in Enum.GetNames(example.GetType()))
{
Console.WriteLine(name);
}
}
and then:
OutputEnumValues((HorizontalAlignment) 0);
OutputEnumValues((VerticalAlignment) 0);
This works for all enum types no matter their underlying integer type.
What you really want here is a Generic method that could constrain to a Enum type. However, that isn't possible in C#.
Jon Skeet has an answer for this very problem in this thread: Anyone know a good workaround for the lack of an enum generic constraint?
For your method what you really want is
public void OutputEnumValues<T>() where T : HorizontalAlignment
{
foreach (string name in Enum.GetNames(typeof(T)))
{
Console.WriteLine(name);
}
}
But that constraint won't work, unless you use Jon's suggestion.
I don't think that this is possible in C#.
You could instead use an extension method on Enum, but this would require you to call it on an instance rather than the type itself which may not be desirable.
An alternative solution using generics that gets you part of the way is to constraint to structs:
public static void OutputValues<T>() where T : struct
{
if (!typeof(T).IsEnum)
throw new NotSupportedException("Argument must be an enum.");
// code here...
}
This will give a compile time error if you try to call it with a class but a runtime error if you call it with a struct that is not an Enum.
I don't see the "problem" as you state it.
You define your method to take a Type object. To clients, any Type would seem sufficient. However, you then assume that the argument is actually an enumeration. The bug is in your method itself. The method itself is contrived anyway, so it's impossible to get an idea of the problem you are actually trying to solve with code like this.
Then again, the name of your method makes it fairly obvious that the argument should be an enum value. You could consider that a contract, and if clients of the code violate that contract than it will blow up in their faces. Any API includes methods that you can send bad data to.
Method overloading allows us to define many methods with the same name but with a different set of parameters ( thus with the same name but different signature ).
Are these two methods overloaded?
class A
{
public static void MyMethod<T>(T myVal) { }
public static void MyMethod(int myVal) { }
}
EDIT:
Shouldn't statement A<int>.MyMethod(myInt); throw an error, since constructed type A<int> has two methods with the same name and same signature?
Are the two methods overloaded?
Yes.
Shouldn't statement A<int>.MyMethod(myInt); throw an error, since constructed type A<int> has two methods with the same signature?
The question doesn't make sense; A is not a generic type as you have declared it. Perhaps you meant to ask:
Should the statement A.MyMethod(myInt); cause the compiler to report an error, since there are two ambiguous candidate methods?
No. As others have said, overload resolution prefers the non-generic version in this case. See below for more details.
Or perhaps you meant to ask:
Should the declaration of type A be illegal in the first place, since in some sense it has two methods with the same signature, MyMethod and MyMethod<int>?
No. The type A is perfectly legal. The generic arity is part of the signature. So there are not two methods with the same signature because the first has generic arity zero, the second has generic arity one.
Or perhaps you meant to ask:
class G<T>
{
public static void M(T t) {}
public static void M(int t) {}
}
Generic type G<T> can be constructed such that it has two methods with the same signature. Is it legal to declare such a type?
Yes, it is legal to declare such a type. It is usually a bad idea, but it is legal.
You might then retort:
But my copy of the C# 2.0 specification as published by Addison-Wesley states on page 479 "Two function members declared with the same names ... must have have parameter types such that no closed constructed type could have two members with the same name and signature." What's up with that?
When C# 2.0 was originally designed that was the plan. However, then the designers realized that this desirable pattern would be made illegal:
class C<T>
{
public C(T t) { ... } // Create a C<T> from a given T
public C(Stream s) { ... } // Deserialize a C<T> from disk
}
And now we say sorry buddy, because you could say C<Stream>, causing two constructors to unify, the whole class is illegal. That would be unfortunate. Obviously it is unlikely that anyone will ever construct this thing with Stream as the type parameter!
Unfortunately, the spec went to press before the text was updated to the final version. The rule on page 479 is not what we implemented.
Continuing to pose some more questions on your behalf:
So what happens if you call G<int>.M(123) or, in the original example, if you call A.MyMethod(123)?
When overload resolution is faced with two methods that have identical signatures due to generic construction then the one that is generic construction is considered to be "less specific" than the one that is "natural". A less specific method loses to a more specific method.
So why is it a bad idea, if overload resolution works?
The situation with A.MyMethod isn't too bad; it is usually pretty easy to unambiguously work out which method is intended. But the situation with G<int>.M(123) is far worse. The CLR rules make this sort of situation "implementation defined behaviour" and therefore any old thing can happen. Technically, the CLR could refuse to verify a program that constructs type G<int>. Or it could crash. In point of fact it does neither; it does the best it can with the bad situation.
Are there any examples of this sort of type construction causing truly implementation-defined behaviour?
Yes. See these articles for details:
https://ericlippert.com/2006/04/05/odious-ambiguous-overloads-part-one/
https://ericlippert.com/2006/04/06/odious-ambiguous-overloads-part-two/
Yes. MyMethod(int myVal) will be called when the type of the parameter is an int, the generic overload will be called for all other parameter arguments, even when the parameter argument is implicitly convertible to (or is a derived class of) the hardcoded type. Overload resolution will go for the best fit, and the generic overload will resolve to an exact match at compile time.
Note: You can explicitly invoke the generic overload and use an int by providing the type parameter in the method call, as Steven Sudit points out in his answer.
short s = 1;
int i = s;
MyMethod(s); // Generic
MyMethod(i); // int
MyMethod((int)s); // int
MyMethod(1); // int
MyMethod<int>(1); // Generic**
MyMethod(1.0); // Generic
// etc.
Yes, they are. They will allow code as such:
A.MyMethod("a string"); // calls the generic version
A.MyMethod(42); // calls the int version
Yes, they are overloaded. The compiler is supposed to prefer explicit method signatures against generic methods if they are available. Beware, however, that if you can avoid this kind of overload you probably should. There have been bug reports with respect to this sort of overload and unexpected behaviors.
https://connect.microsoft.com/VisualStudio/feedback/details/522202/c-3-0-generic-overload-call-resolution-from-within-generic-function
Yes. They have the same name "MyMethod" but different signatures. The C# specification, however, specifically handles this by saying that the compiler will prefer the non-generic version over the generic version, when both are options.
Yes. Off the top of my head, if you call A.MyMethod(1);, it will always run the second method. You'd have to call A.MyMethod<int>(1); to force it to run the first.