Method from interface is virtual or not?

  • Thread starter Thread starter Vladimir Bezugliy
  • Start date Start date
V

Vladimir Bezugliy

I have next interface:
interface I
{
void F();
}

And next class implements this interface:
class MyClass : I
{
void F(){};
}

What does the modifier have the method MyClass::F() by
default?
 
Public. Interface implementation members are always public, and you can't
put a visibility modifier in front of them, so you can't make them anything
but public.
 
What does the modifier have the method MyClass::F() by
Public. Interface implementation members are always public, and you can't
put a visibility modifier in front of them, so you can't make them anything
but public.
Click to expand...

I am sorry, but you do not understand me right.
What does the modifier of the method from an interface -
"virtual" or "virtual sealed"?
As far as I see by ILDASM - method called as virtual
(callvirt).
But VisualStudio do not add any modifier in front of this
method.
And I can not override this method in derived classes.
I should explicitly add word "virtual" in front of the
method.
Why?
 
What does the modifier have the method MyClass::F() by
Public. Interface implementation members are always public, and you can't
put a visibility modifier in front of them, so you can't make them anything
but public.
Click to expand...

I am sorry, but you do not understand me right.
What does the modifier of the method from an interface -
"virtual" or "virtual sealed"?
As far as I see by ILDASM - method called as virtual
(callvirt).
But VisualStudio do not add any modifier in front of this
method.
And I can not override this method in derived classes.
I should explicitly add word "virtual" in front of the
method.
Why?
 
I am sorry, but you do not understand me right.
What does the modifier of the method from an interface -
"virtual" or "virtual sealed"?
As far as I see by ILDASM - method called as virtual
(callvirt).
But VisualStudio do not add any modifier in front of this
method.
And I can not override this method in derived classes.
I should explicitly add word "virtual" in front of the
method.
Why?
Click to expand...

Why not? Why would you expect interface implementations to
automatically be virtual? They may be *called* virtually via the
interface, but I see no reason to make them virtual (in terms of being
able to be overridden) by default.
 
I am sorry, but you do not understand me right.
What does the modifier of the method from an interface -
"virtual" or "virtual sealed"?
Click to expand...

None of the above.
As far as I see by ILDASM - method called as virtual
(callvirt).
Click to expand...

That's for security purposes. It ensures that the method is not being called
on an invalid object pointer. .virtcall is used most everywhere except for
static methods.
But VisualStudio do not add any modifier in front of this
method.
Click to expand...

Well, it will add 'public' unless you're using explicit implementation.
And I can not override this method in derived classes.
I should explicitly add word "virtual" in front of the
method.
Why?
Click to expand...

Because that's the way .NET works with interfaces. AFAIK as long as there
are matching accessible members of the class that match the ones on the
interface then everyone's happy.
 
Why not? Why would you expect interface implementations
to automatically be virtual?


Because interfaces in Java and in C++(pure abstract
classes) works this way.
 
But how does CLR discern where is plain function from
interface and where is virtual function from interface?
See code below.

interface I
{
void F();
}

class Plain : I
{
public void F(){}
}

class Virt : I
{
public virtual void F(){}
}

As far as I see - ILDASM generate the same .callvirt.
 
Vladimir Bezugliy said:
to automatically be virtual?

Because interfaces in Java and in C++(pure abstract
classes) works this way.
Click to expand...

It's not *interfaces* that work that way in Java - it's *all* methods
which are virtual by default.
 
Vladimir,
As far as I see - ILDASM generate the same .callvirt.
Click to expand...

C# code almost always use the callvirt instruction regardless whether
the callee actually is virtual or not. The reason is that callvirt
checks if the this reference is null and throws a
NullReferenceException if it is, which is the specified behavior for
C#.



Mattias
 
Back
Top