The main reason that methods are not virtual by default in C# is because virtual methods allow derived classes to alter the contract between a base class and the user of a class, without the base class having any control over how this is done, or even knowledge that this is being done. In other words, if a base class calls a non-virtual method, it knows exactly what will happen. The developer can rely on the behavior, can test it, and can have some assurance that it will do the same thing when someone else uses the class -- even if they derive another class from it. Obviously, if the developer wants the method to be overridable, she can.
I find default-virtual to be a huge source of headaches in large Java projects, and I'm very, very glad that C# is strict about when methods are virtual, and when they are overridden. Another good reason is that it simplifies (i.e. makes possible!) the security system of C#. If every method was virtual, then developers would need to be much, much more careful about security boundaries (trusted library being called by untrusted client code). -- arlie -----Original Message----- From: Discussion of advanced .NET topics. [mailto:[EMAIL PROTECTED] On Behalf Of Stoyan Damov Sent: Friday, July 07, 2006 7:57 PM To: ADVANCED-DOTNET@DISCUSS.DEVELOP.COM Subject: Re: [ADVANCED-DOTNET] Virtual methods in .NET - was Implementing an Interface - C# vs. VB.NET On 7/8/06, David Lanouette <[EMAIL PROTECTED]> wrote: > Anybody know why methods aren't virtual by default in .NET? It seems > like a really bad default to have all methods non-virtual. Because in theory, there's an overhead in calling a virtual as opposed to non-virtual method. In practice, if you have a performance hit from the fact that you're calling virtual methods, you shouldn't write your program for .NET anyway. On a side note, all instance methods in Java are by default virtual and you have to specifically mark them as non-virtual with the final keyword. Now, from my experience, one non-trivial application has a lot more non-virtual instance methods than virtual and I guess that's the (practical) reason for Microsoft to choose non-virtual methods by default and have the virtual/overridable/whatever keywords. C# (and I believe VB.NET) is a different story - the compiler emits code that performs virtual calls on both virtual and non-virtual methods to guard you from the stupid mistake to call a non-virtual method on a null instance, e.g.: class X { public void Foo() { } } X x = null; x.Foo(); // was OK in the early days, now throws NullPointerException because Foo is called as a virtual method (w/ callvirt). There's no overhead in calling a non-virtual function w/ callvirt, so the compiler "hack" is a good thing. Cheers, Stoyan =================================== This list is hosted by DevelopMentorR http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com =================================== This list is hosted by DevelopMentor® http://www.develop.com View archives and manage your subscription(s) at http://discuss.develop.com
