Slow performance compared to C++, ideas?

John Colvin john.loughran.colvin at gmail.com
Tue Jun 4 05:29:08 PDT 2013


On Tuesday, 4 June 2013 at 05:22:39 UTC, Andrei Alexandrescu 
wrote:
> Situation: I have a closed source library I want to use. I test 
> and find that it doesn't meet our requirements for some trivial 
> matter like the behavior of a few methods (super common, I 
> assure you).
> The author is not responsive, possibly because it would be a 
> potentially breaking change to all the other customers of the 
> library, I've now wasted a month of production time in 
> discussions in an already tight schedule, and I begin the 
> process of re-inventing the wheel.
> I've spent 10 years repeating this pattern. It will still be 
> present with virtual-by-default, but it will be MUCH WORSE with 
> final-by-default. I don't want to step backwards on this front.
>
> Destroyed?

I don't buy this.

Overriding a method from a class in a closed source library is 
only a sane thing to do if the docs explicitly say you can.
If the docs explicitly say you can, then one can assume that the 
author will have marked it virtual.

This virtual-by-default flexibility only exists when you're 
working with classes that you understand the internals of.


Consider these situations, assuming lazy but not completely 
incompetent library authors:

Hidden source, virtual by default:
     You can override most things, but you're playing with fire 
unless you have a written promise that it's safe to do so.

Open source, virtual by default:
     Once you understand the internals of a class, you can safely 
override whatever you want. You are exposed to breakage due to 
implementation detail, but documentation represents a promise of 
sorts.

Hidden source, final by default:
     You can only override what the author allows you to. This 
will have at least some connection with what is safe to override.

Open source, final by default:
     Once you understand the internals of a class, you can fork 
the library and add virtual on the methods you need to override 
that the author did not consider.*



Basically, final-by-default is safer and faster, 
virtual-by-default is more convenient when working with open 
source libraries.



* you might consider this an unacceptable extra burden, 
especially considering distribution problems. However, I would 
counter that if you're going to override a method that isn't 
explicitly intended to be, you are exposing yourself to breakage 
due to implementation detail and therefore it would be 
distributing your own version anyway.


More information about the Digitalmars-d mailing list