Consider, I have the following 3 classes / interfaces:
class MyClass<T> { }
interface IMyInterface { }
class Derived : IMyInterface { }
And I want to be able to cast a MyClass<Derived> into a MyClass<IMyInterface> or visa-versa:
MyClass<Derived> a = new MyClass<Derived>();
MyClass<IMyInterface> b = (MyClass<IMyInterface>)a;
But I get compiler errors if I try:
Cannot convert type 'MyClass<Derived>' to 'MyClass<IMyInterface>'
I'm sure there is a very good reason why I cant do this, but I can't think of one.
As for why I want to do this - The scenario I'm imagining is one whereby you ideally want to work with an instance of MyClass<Derived> in order to avoid lots of nasty casts, however you need to pass your instance to an interface that accepts MyClass<IMyInterface>.
So my question is twofold:
Why can I not cast between these two types?
Is there any way of keeping the niceness of working with an instance of MyClass<Derived> while still being able to cast this into a MyClass<IMyInterface>?
This does not work because C# only supports covariance on the type parameters of interfaces and delegates. If your type parameter exists only in output positions (i.e. you only return instances of it from your class and don't accept it as an argument) you could create an interface like this:
interface IClass<out T> { }
class MyClass<T> : IClass<T> { }
Which would allow you to do this:
IClass<Derived> a = new MyClass<Derived>();
IClass<IMyInterface> b = a;
Honestly that is about as close as you are going to get and this requires the C# 4 compiler to work.
The reason you cannot do this in general is because most classes are not simple empty examples. They have methods:
class MyClass<T>
{
static T _storage;
public void DoSomethingWith(T obj)
{
_storage = obj;
}
}
interface IMyInterface { }
class Derived : IMyInterface { }
MyClass<Derived> a = new MyClass<Derived>();
Now, a has a method DoSomethingWith that accepts a Derived and stores it in a static variable of type Derived.
MyClass<IMyInterface> b = (MyClass<IMyInterface>)a;
If that was allowed, b would now appear to have a method DoSomethingWith that accepts anything that implements IMyInterface, and would then internally attempt to store it in a static variable of type Derived, because it's still really the same object referred to by a.
So now you'd have a variable of type Derived storing... who knows what.
Related
I am trying to attempt something such as
void Main()
{
Temp<Bar> Test = new Foo<InheritedBar>();
}
abstract class Temp<T> where T : Bar
{
}
class Foo<T> : Temp<T> where T : Bar
{
}
abstract class Bar
{
}
class InheritedBar : Bar
{
}
The cast does not work, with the error Cannot implicity convert type Foo<InheritedBar> to Temp<Bar>.
However,
Temp<InheritedBar> Test = new Foo<InheritedBar>();
and
Temp<Bar> Test = new Foo<Bar>();
Both work. Why even though InheritedBar inherits from Bar, it can't be cast to it through generics?
I am using the generic type in a wpf Page, which can not be created as a generic so I can't pass T as its type. I only want the functionality at the time of this of Temp, not any of the derived versions functionality. Is there a better way to do this?
The concept you are attempting to utilize is covariance (full explanation on MSDN)
The short answer is that you need to use mark your generic parameter with out; but you can only do that on an interface (changing from an abstract class in your case). Also, depending on your method parameters and return values, you may not be able to mark your interface as covariant.
interface Temp<out T> where T : Bar
{
}
I'm having a hard time understanding why it would be beneficial to do something like this: (Sample is a class)
static void PrintResults<T>(T result) where T : Sample
Wouldn't it be better to to just pass Sample into the method?
static void PrintResults (Sample result)
I recommend avoiding generic types where non-generic syntax works, such as the example you gave. However, there are other useful cases.
For example, specifying the return type generically:
static T Create<T>() where T: Sample, new()
{
return new T();
}
// Calling code
Sample sample = Create<Sample>();
instead of
static object Create()
{
return new Sample();
}
// Calling code
Sample sample = (Sample) Create();
You can also use templates to place multiple restrictions on a type. For example:
static T Create<T>() where T: IMyInterface, new()
{
return new T();
}
interface IMyInterface {}
class MyClass : IMyInterface { }
// Calling code.
MyClass myClass = Create<MyClass>();
This allows the generic creation of a new type that implements a specific interface and has a generic constructor. Also:
static void DoSomething<T>(T t) where T: IMyInterface1, IMyInterface2
{
t.MethodOnIMyInterface1();
t.MethodOnIMyInterface2();
}
interface IMyInterface1
{
void MethodOnIMyInterface1();
}
interface IMyInterface2
{
void MethodOnIMyInterface2();
}
class MyClass: IMyInterface1, IMyInterface2
{
// Method implementations omitted for clarity
}
// Calling code
MyClass myclass'
DoSomething(myclass); // Note that the compiler infers the type of T.
Where you can require multiple interfaces on a single parameter without (1) creating a new type that implements all these interfaces and (2) requiring parameters to be of that type.
As #dcastro points out in his/her answer, generic types can also tell the compiler to require types are the same. For example:
static void DoSomething<T>(T t1, T t2) where T: MyType
{
// ...
}
class MyType {}
class MyType1: MyType {}
class MyType2: MyType {}
// Calling code
MyType1 myType1;
MyType2 myType2;
DoSomething<MyType>(myType1, myType2);
Where the compiler requires that t1 and t2 are the same type but can be any type that inherits MyType. This is useful in automated unit testing frameworks, such as NUnit or MSTest, for generic equality and comparison checks.
Most of the answers are offering explanations of the usefulness of generics involving interfaces that don't really seem to address your actual question.
Truth is, for the example you posted, there is no benefit to using a generic method. It is actually worse because it will cause multiple implementations of the same function to be generated and ever slightly increase the code size at runtime.
In voids you could allways use an interface as a parameter to make multiple types work, so generics arent often useful here.
Only exceptions are the constraints on generics. And by that i dont mean something like
where T: IA, IB
since this could be done by an interface aswell that both implements IA and IB. This will get tiresome at some point however since you will need more and more interfaces. So lets look ath the "special constraints" class and new
public void AddNew(List<T> items) where T : new
{
items.Add(new T());
}
and class which is useful if the method mutates its parameter, which wont work for structs
static void IncA<T>(T item) where T: class, IA
{
item.A++;
}
The real power of generics is when methods have a generic return type or generic classes like List <T>. You dont want to implement a new class for every List you will need.
I haven't found my use case in the existing questions so here I go.
I have an abstract class that has generics like this :
public abstract class aParameter<T>
{
private T _parameter;
public T Parameter
{
get { return _parameter;}
}
...
}
Then I have my "Type" classes like this :
public class IntParameter : aParameter<Int32>
{
public IntParameter(Int32 value)
{
_parameter = value;
}
}
public class TextParameter : aParameter<String>
{
public TextParameter(String value)
{
_parameter = value;
}
}
Now in my application code, I'd like to create a dictionary with the abstract generic class without specifying the generic type. Like this :
...
private Dictionary<Int32, aParameter> _paramDict = new Dictionary<Int32, aParameter>();
...
In a previous version, I used interfaces instead of abstract class for aParameter but I wanted to migrate it to abstract so that I could simplify my "Type" classes and not repeat identical code for each "Type".
Any thoughts here?
EDIT
I forgot to mention that it will be part of a library that is meant to be distributed among the company so I really need to secure the allowed types. I can't allow for just objects to be fed into my code.
You probably still going to need the non-generic interface (or nongeneric abstract base class as Brandon says), unless you drop to working with objects.
The reason is that aParameter<String> is not the same type as aParameter<int32> so you'll not be able to get them into the one dictionary without some help.
My preferred method around this is to declare a non-generic interface and use that as the basis for the dictionary, then implement it in each of your typed generics, and also in an abstract base class. That way you can inherit from the base class where possible, or just implement the interface if one of your types needs to inherit from something else - you get maximum flexibility.
Make a non-generic abstract base class and have your generic abstract class inherit from it.
The purpose of generic types is (among other things) that you can only write code once that can be used for multiple types. However, as C# is strongly types, the compiler needs to know what types it is dealing with in the generic class. This is why you have to specify the type of the generic (i.e. the type in angled brackets)
If you don't specify the type of the generic then, in your example, the compiler wouldn't know the type of the Parameter property.
Depending on exactly what you're doing with it, there are a number of possible approaches:
Use a Dictionary<int, object>.
When reading the values, you can use a bunch of if/elses to check the specific type of the object and convert to the appropriate type. e.g.
if(obj.GetType() == typeof(TextParameter))
{
TextParameter p = obj as TextParameter
// Do stuff
}
else if obj.GetType() == typeof(IntParameter))
{
IntParameter p = obj as IntParameter
// Do stuff
}
Have multiple dictionaries. Dictionary<int, TextParameter>, Dictionary<int, IntParameter>, etc.
If there are methods/properties in aParameter that are not type dependent then move them to a lower level non-generic abstract class. This could give you at least some of your functionality without having to resort to type conversions.
I have a simple factory method which provides a concrete implementation instance based on a generic type parameter provided. If the concrete classes inherit from a common abstract base class with a type parameter I cannot cast them. The compiler tells me Error 2 Cannot convert type 'Car' to 'VehicleBase<T>'. It works fine if I substitute the abstract class for an interface with the same type parameter, or if I remove the generic type parameter from the abstract class.
interface IWheel
{
}
class CarWheel : IWheel
{
}
abstract class VehicleBase<T>
{
}
class Car : VehicleBase<CarWheel>
{
}
class VehicleFactory
{
public static VehicleBase<T> GetNew<T>()
{
if (typeof(T) == typeof(CarWheel))
{
return (VehicleBase<T>)new Car();
}
else
{
throw new NotSupportedException();
}
}
}
This fails to compile on (VehicleBase<T>)new Car(). Is this a compiler defect, or could this be a deliberate design decision to treat abstract classes and interfaces with type parameters differently?
As a workaround I can always make the abstract class implement an interface and use this as the return value for my factory method, but I'd still like to know why this behavior is happening.
That is not provable, because generic code needs to work (with the same IL) for every possible T, and there is nothing to say that Car : VehicleBase<float>, for example. The compiler does not over-analyse the fact that the if check sows that T is CarWheel - the static checker treats each statement separately, it doesn't try to understand the cause-and-effect of conditions.
To force it, cast to object in the middle:
return (VehicleBase<T>)(object)new Car();
However! Your approach isn't really "generic" as such.
This is neither a compiler defect nor a deliberate decision. Type parameters on generic classes are neither covariant nor contravariant, ie there is no inheritance relationship between specializations of the same generic class. From the docs:
In the .NET Framework version 4, variant type parameters are restricted to generic interface and generic delegate types.
Which means that the following code will compile, because it uses an interface instead of an abstract class:
interface IWheel
{
}
class CarWheel : IWheel
{
}
interface IVehicleBase<T>
{
}
class Car : IVehicleBase<CarWheel>
{
}
class VehicleFactory
{
public static IVehicleBase<T> GetNew<T>()
{
if (typeof(T) == typeof(CarWheel))
{
return (IVehicleBase<T>)new Car();
}
else
{
throw new NotSupportedException();
}
}
}
Check "Covariance and Contravariance in Generics" for more info and examples.
There is also a Covariance and Contravariance FAQ at the C# FAQ blog with more info, and an 11-part series! on the subject by Eric Lippert
This seems to work:
return new Car() as VehicleBase<T>;
My guess why it is that way:
As generic type instances of VehicleBase<T> are not related, it cannot be proven that casting them could work:
If T is of type Blah, the cast would not work. You can't go back to object and then take the other branch (there's no multiple inheritance in C# after all).
By casting it back to object before, you are again opening the possibility that the cast might work, because there might still be a path down to VehicleBase<CarWheel>. An interface, of course, can appear anywhere in this tree below object, so that should work, too.
I'm working on a small class library at work, and it naturally involves using generics for this task. But there is this thing that I don't really understand with generics:
Why would I need to use generic type parameters, and then constrain the the type parameter to a specific base class or interface.
Here's an example to what I mean:
public class MyGenericClass<T> where T : SomeBaseClass
{
private T data;
}
And here's the implementation without generics
public class MyClass
{
private SomeBaseClass data;
}
Are these two definitions the same (if yes, then i don't see the advatage of using generics here)?
If not, what do we benefit from using generics here?
As with almost all uses of generics, the benefit comes to the consumer. Constraining the type gives you the same advantages that you get by strongly typing your parameter (or you can do other things like ensure that there's a public parameterless constructor or ensure that it's either a value or reference type) while still retaining the niceties of generics for the consumer of your class or function.
Using generics also, for example, allows you to obtain the actual type that was specified, if that's of any particular value.
This example is a little contrived, but look at this:
public class BaseClass
{
public void FunctionYouNeed();
}
public class Derived : BaseClass
{
public void OtherFunction();
}
public class MyGenericClass<T> where T: BaseClass
{
public MyGenericClass(T wrappedValue)
{
WrappedValue = wrappedValue;
}
public T WrappedValue { get; set; }
public void Foo()
{
WrappedValue.FunctionYouNeed();
}
}
...
var MyGenericClass bar = new MyGenericClass<Derived>(new Derived());
bar.Foo();
bar.WrappedValue.OtherFunction();
The difference is that the former defines the new class as a specific type; the latter simply defines a plain class with a field of that type.
It's all about type safety. Using generics you can return a concrete type (T) instead of some base type which defines the API you need in your generic class. Therefore, the caller of your method won't have to cast the result to the concrete type (which is an error-prone operation).
The main difference is in usage. In the first case, the usage can have:
MyGenericClass<SomeDerivedClass> Variable
Variable.data.SomeDerivedProperty = X
And so that when you use that class, you can still access anything from SomeDerivedClass without casting back to it.
The second example will not allow this.
MyClass.data = SomeDerivedClassInstance
MyClass.data.SomeDerivedProperty = X //Compile Error
((SomeDerivedClass)MyClass.data).SomeDerivedProperty = X //Ewwwww
You will have to cast back up to the SomeDerivedClass (which is unsafe) to use something specific to the derived class.
I don't think that there is a huge amount of difference except that the generic version is constraining your Class, whereas the second is just a constraint on a member of the class. If you added more members and methods to your first Class, you would have the same constraint in place.