Is every abstract function virtual in c#, in general?

Question

I was looking at this question and I was wondering whether every abstract function should be considered to be a virtual function in C# or in general?

I was a bit puzzled by the "you must override/you may override" responses to that question. Not being a C# programmer, I tend to think that abstract functions are a compile-time concept only, and that abstract functions are virtual functions by definition since you must provide at least one but can provide multiple implementations further down the hierarchy. Virtual functions have a compile-time dimension too, in that you cannot override a non-virtual function, but is mostly a runtime concept since it is "just" the selection of the correct method implementation based on the actual receiver.

Answer 1

Yes, it is. For proof:

abstract class A {
    public abstract void Foo();
}
class B : A {
    public override void Foo()
    { /* must do */ }
}
class C : B {
    public override void Foo()
    { /* can do */ }
}

Answer 2

Yes.

An abstract property declaration specifies that the accessors of the property are virtual, but does not provide an actual implementation of the accessors. (MSDN)

Answer 3

Yes. From section 10.6.6 of the C# 3.0 spec:

When an instance method declaration includes an abstract modifier, that method is said to be an abstract method. Although an abstract method is implicitly also a virtual method, it cannot have the modifier virtual.

Answer 4

I think you are looking at the problem from a "C++" point of view (be terse, avoid necessary keywords, save keystrokes).

The C# philosophy is the the intent of the code should be clear from reading the source, and the compiler should be able to verify that intention as much as possible.

So, while there is very little different in the generated MSIL between an abstract method and a virtual method (or for that matter, between an abstract and a non-abstract class; or between an out parameter and a ref parameter), the extra keywords do tell maintenance programmers something, and allow the compiler the double check what you are doing.

Answer 5

It has to be virtual (and Jon Skeet has already whipped out the spec to prove that it is), because, given a reference to the abstract base class, the concrete derived class's implementation must be called. For example, given the classic Animal hierarchy:

abstract class Animal{
    public abstract void Speak();
}

class Cat : Animal{
    public override void Speak(){Console.WriteLine("meow");}
}

class Dog : Animal{
    public override void Speak(){Console.WriteLine("bark");}
}

A function that takes an Animal object, and calls its Speak method wouldn't know which implementation to call if the function weren't virtual.

static void TalkToAnimal(Animal a){
    Console.WriteLine("Hello, animal.");
    a.Speak();
}

Note however, that interface implementations are not virtual by default. Because an interface works differently from a class, true polymorphism isn't necessary to find the implementation of an interface method.