Slow performance compared to C++, ideas?

Jonathan M Davis jmdavisProg at gmx.com
Mon Jun 3 17:18:45 PDT 2013


On Monday, June 03, 2013 19:06:53 David Nadlinger wrote:
> On Monday, 3 June 2013 at 16:25:24 UTC, Manu wrote:
> > You won't break every single method, they already went through
> > that recently when override was made a requirement. […] A much
> > smaller number than the breakage
> > which was gladly accepted recently. […] how did the override
> > change ever get accepted […]
> 
> It appears as if either you have a interesting definition of
> "recently", or you are deliberately misleading people by bringing
> up that point over and over again.
> 
> According to http://dlang.org/changelog.html, omitting "override"
> produced a warning since D 2.004, which was released back in
> September 2007! Granted, it was only actually turned from a
> deprecation warning into an actual deprecation in 2.061 (if my
> memory serves me right), but it's mostly a flaw in the handling
> of that particular deprecation that it stayed at the first level
> for so long. The actual language change was made – and
> user-visible – almost six (!) years ago, which is a lot on the D
> time scale.

Except that because it was only treated as a warning until very recently and 
because dmd has the abnormal behavior of not printing warnings by default, 
plenty of folks weren't using override until quite recently.

> You are also ignoring the fact that in contrast to requiring
> "override", there is no clean deprecation path for your proposal,
> at least as far as I can see: Omitting the keyword started out as
> a warning, and IIRC still is allowed when you enable deprecated
> features via the compiler switch. How would a similar process
> look for virtual-by-default? As far as am isolated module with
> only a base class is concerned, this is not question of valid vs.
> invalid code, but a silent change in language semantics.

The change in semantics isn't very silent at all thanks to override. It 
actually breaks quite loudly. Historically, the steps to do it would have been 
something like

1. Print a message or warning that a function which is being overridden isn't 
marked as virtual.

2. Deprecate overriding a function which is not marked as virtual.

3. Make it an error to override a function which isn't marked as virtual and 
then actually make it so that functions which are not marked as virtual are 
non-virtual.

But now that deprecations don't stop compilation by default anymore, we might 
even be able to skip the first step and do

1. Deprecate overriding a function which is not marked as virtual.

2. Make it an error to override a function which isn't marked as virtual and 
then actually make it so that functions which are not marked as virtual are 
non-virtual.

And the only functions which have to be changed are those which are actually 
being overridden, and the compiler will already give an error when you 
override a function without marking the overriding function with override, so 
programmers are already forced to mark all of the functions that care whether 
the base class function is virtual or not. So, you won't be getting silent 
breakage. It's more of a problem when a library writer puts an API in their 
library and does not actually override it themselves (even if it's intended to 
be overridden), as it's the users of that library which will see the 
deprecation warnings and eventual breakage, but the library writer should be 
testing their own stuff, and the users of the library can yell at them about 
it.

So, the breakage is minimal and noisy, but it _is_ still breakage. If we were 
starting from scratch, I really don't think that there would be much excuse 
for not making functions non-virtual by default given that we require 
overriding functions to be marked with override, but it is more of an open 
question when we're this far into the game. I still think that it's worth 
making the change though.

- Jonathan M Davis


More information about the Digitalmars-d mailing list