<div dir="ltr">On 2 June 2013 20:16, Jonathan M Davis <span dir="ltr"><<a href="mailto:jmdavisProg@gmx.com" target="_blank">jmdavisProg@gmx.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Sunday, June 02, 2013 11:53:26 Jacob Carlborg wrote:<br>
> On 2013-06-01 23:08, Jonathan M Davis wrote:<br>
> > If you don't need polymorphism, then in general, you shouldn't use a class<br>
> > (though sometimes it might make sense simply because it's an easy way to<br>
> > get a reference type). Where it becomes more of a problem is when you<br>
> > need a few polymorphic functions and a lot of non-polymorphic functions<br>
> > (e.g. when a class has a few methods which get overridden and then a lot<br>
> > of properties which it makes no sense to override). In that case, you<br>
> > have to use a class, and then you have to mark a lot of functions as<br>
> > final. This is what folks like Manu and Don really don't like,<br>
> > particularly when they're in environments where the extra cost of the<br>
> > virtual function calls actually matters.<br>
> If a reference type is needed but not a polymorphic type, then a final<br>
> class can be used.<br>
<br>
</div></div>Yes. The main problem is when you have a class with a few methods which should<br>
be virtual and a lot that don't. You're forced to mark a large number of<br>
functions as final. That burden can be lessened by using final with a colon<br>
rather than marking them individually, but rather what seems to inevitably<br>
happen is that programmers forget to mark any of them as final (Manu can rant<br>
quite a bit about that, as he's had to deal with it at work, and it's cost him<br>
quite a bit of time, as he has to go through every function which wasn't<br>
marked as final and determine whether it's actuallly supposed to be virtual or<br>
not). Having non-virtual be the default makes functions efficient by default.<br></blockquote><div><br></div><div style>Aye. This, and maybe even a more important result is it makes it _explicit_ by default. Ie, it was intended by the author.</div>
<div style>You can tell just by looking how the interface is intended to be used, and the intent of the programmer who wrote it.</div><div style><br></div><div style>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...?</div>
<div style><br></div><div style>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.</div>
<div style>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.</div><div style><br></div><div style>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.</div>
<div style>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.</div>
</div></div></div>