You can re-declare (new), but you can’t re-declare and override at the same time (with the same name). One option is to use a protected method to hide the detail – this allows both polymorphism and hiding at the same time: public class Father { public Father SomePropertyName { get { return SomePropertyImpl(); } } … Read more
vector<Base*> and vector<Derived*> are unrelated types, so you can’t do this. This is explained in the C++ FAQ here. You need to change your variable from a vector<Derived*> to a vector<Base*> and insert Derived objects into it. Also, to avoid copying the vector unnecessarily, you should pass it by const-reference, not by value: void BaseFoo( … Read more
UPDATE: This answer was written in 2011. After two decades of people proposing return type covariance for C#, it looks like it will finally be implemented; I am rather surprised. See the bottom of https://devblogs.microsoft.com/dotnet/welcome-to-c-9-0/ for the announcement; I’m sure details will follow. First off, return type contravariance doesn’t make any sense; I think you … Read more
Variance only works for reference-types (or there is an identity conversion). It is not known that TBase is reference type, unless you add : class: public void Foo<TBase>() where TBase : class, IBase since I could write a: public struct Evil : IBase {}
Because it would break type-safety otherwise. If not, you would be able to do something like this: val arr:Array[Int] = Array[Int](1,2,3) val arr2:Array[Any] = arr arr2(0) = 2.54 and the compiler can’t catch it. On the other hand, lists are immutable, so you can’t add something that is not Int
You could write your own read-only wrapper for the dictionary, e.g.: public class ReadOnlyDictionaryWrapper<TKey, TValue, TReadOnlyValue> : IReadOnlyDictionary<TKey, TReadOnlyValue> where TValue : TReadOnlyValue { private IDictionary<TKey, TValue> _dictionary; public ReadOnlyDictionaryWrapper(IDictionary<TKey, TValue> dictionary) { if (dictionary == null) throw new ArgumentNullException(“dictionary”); _dictionary = dictionary; } public bool ContainsKey(TKey key) { return _dictionary.ContainsKey(key); } public IEnumerable<TKey> Keys … Read more
Simply put, IList<T> is not covariant, whereas IEnumerable<T> is. Here’s why… Suppose IList<T> was covariant. The code below is clearly not type-safe… but where would you want the error to be? IList<Apple> apples = new List<Apple>(); IList<Fruit> fruitBasket = apples; fruitBasket.Add(new Banana()); // Aargh! Added a Banana to a bunch of Apples! Apple apple = … Read more
Imagine you create a list of Dogs. You then declare this as List<Animal> and hand it to a colleague. He, not unreasonably, believes he can put a Cat in it. He then gives it back to you, and you now have a list of Dogs, with a Cat in the middle of it. Chaos ensues. … Read more
The simplest way to understand why this is not allowed is the following example: abstract class Fruit { } class Apple : Fruit { } class Banana : Fruit { } // This should intuitively compile right? Cause an Apple is Fruit. List<Fruit> fruits = new List<Apple>(); // But what if I do this? Adding … Read more
First off, as Tomas says, it is not supported in the CLR. Second, how would that work? Suppose you have class C<out T> { … how are you planning on using T in here? … } T can only be used in output positions. As you note, the class cannot have any field of type … Read more