Slow performance compared to C++, ideas?

Peter Alexander peter.alexander.au at gmail.com
Tue Jun 4 02:20:02 PDT 2013


On Tuesday, 4 June 2013 at 05:58:32 UTC, Andrei Alexandrescu 
wrote:
> On 6/4/13 1:16 AM, Manu wrote:
>> But unlike the first situation, this is a breaking change. If 
>> you are
>> not the only user of your library, then this can't be done 
>> safely.
>
> Same fallacy all over again, for the third time in this thread. 
> You keep on going about "breaking change" without recognizing 
> that the now broken code was happily taking advantage of the 
> very flexibility that you argue was useless and needed fixing.

I believe Manu's point is that the original flexibility was a 
mistake: the author of the library never intended for the method 
to be overridden; it was an accident of virtual-by-default. The 
fact that overriding methods on the class works for a client is 
just a coincidence, and could be dangerous.

The problem occurs when, later, the author profiles and notices 
that the virtual methods are causing performance issues, or 
notices that the method should not have been virtual (perhaps he 
relies on the base behaviour's semantics). Marking it final now 
would be a breaking change for the client relying on the 
accidental virtual functions.

If things were final by default, then you would have to opt-in to 
virtual, so it is unlikely that you will mark a method virtual by 
accident. There is no breakage changing a method from final to 
virtual.

FWIW: I think making method final by default now would cause too 
much breakage, but I do agree with Manu that it would have been a 
better choice in the beginning.


More information about the Digitalmars-d mailing list