Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Sun Jun 2 07:14:03 PDT 2013


On 2 June 2013 20:16, Jonathan M Davis <jmdavisProg at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130603/fef377d5/attachment.html>


More information about the Digitalmars-d mailing list