On 2 June 2013 20:16, Jonathan M Davis <jmdavisProg@gmx.com> wrote:
On Sunday, June 02, 2013 11:53:26 Jacob Carlborg wrote:
> On 2013-06-01 23:08, Jonathan M Davis wrote:
> > If you don't need polymorphism, then in general, you shouldn't use a class
> > (though sometimes it might make sense simply because it's an easy way to
> > get a reference type). Where it becomes more of a problem is when you
> > need a few polymorphic functions and a lot of non-polymorphic functions
> > (e.g. when a class has a few methods which get overridden and then a lot
> > of properties which it makes no sense to override). In that case, you
> > have to use a class, and then you have to mark a lot of functions as
> > final. This is what folks like Manu and Don really don't like,
> > particularly when they're in environments where the extra cost of the
> > virtual function calls actually matters.
> If a reference type is needed but not a polymorphic type, then a final
> class can be used.

Yes. The main problem is when you have a class with a few methods which should
be virtual and a lot that don't. You're forced to mark a large number of
functions as final. That burden can be lessened by using final with a colon
rather than marking them individually, but rather what seems to inevitably
happen is that programmers forget to mark any of them as final (Manu can rant
quite a bit about that, as he's had to deal with it at work, and it's cost him
quite a bit of time, as he has to go through every function which wasn't
marked as final and determine whether it's actuallly supposed to be virtual or
not). Having non-virtual be the default makes functions efficient by default.

Aye. This, and maybe even a more important result is it makes it _explicit_ by default. Ie, it was intended by the author.
You can tell just by looking how the interface is intended to be used, and the intent of the programmer who wrote it.

No more guessing, or lengthy searches through all derived classes to find out if it actually is overridden. And what if your interface is public...?

Making a function virtual is a one-way trip, it can never be revoked. Making it virtual-by-default eliminates the possibility of revoking that permission to override ever in the future.
The converse isn't true, a non-virtual can safely become virtual at any later time if it becomes a requirement, or is requested by a customer.

There's some correctness advantages too. A function that's not marked virtual was obviously not intended to be overridden by design; the author of the class may have never considered the possibility, and the class might not even work if someone unexpectedly overrides it somewhere.
If virtual is requested/added at a later time, the author, when considering if it's a safe change, will likely take the time to validate that the new usage (which he obviously didn't consider when designing the class initially) is sound against the rest of the class... this is a good thing if you ask me.