Slow performance compared to C++, ideas?

Steven Schveighoffer schveiguy at yahoo.com
Thu Jun 6 08:00:34 PDT 2013


On Wed, 05 Jun 2013 21:14:08 -0400, Jonathan M Davis <jmdavisProg at gmx.com>  
wrote:

> On Wednesday, June 05, 2013 17:49:17 Walter Bright wrote:
>> I think we accomplish this in a simpler way:
>>
>> 1. 'virtual' means a method is an "introducing" one.
>> 2. 'override' means a method overrides a base virtual function with a  
>> final
>> function.
>> 3. 'override virtual' means override with a non-final function.
>> 4. none means final and non-overriding.
>
> I would have expected something more like
>
> 1. 'virtual' means a method is an "introducing" one.
> 2. 'override' means override with a non-final function.
> 3. 'final override' means a method overrides a base virtual function  
> with a
> final function.
> 4. 'final' by itself both mean final and non-overriding.

I agree, I think it can be expressed by answering two questions:

1. Do you want to participate in a base class' virtual call
2. Do you want to allow derived classes to participate in the virtual call.

If you answer yes to 1, add override, otherwise (or if there is no base  
method), add nothing (in C# answering no, you should add 'new' if there is  
an existing base function)
If you answer yes to 2, add virtual, otherwise, add final.

But there are a couple of defaults I think are important to establish:
- With no specific storage classes, the default is non-overriding, final.
- When override is specified, the default for allowing participation up  
the chain switches to virtual.  So explicitly stating virtual is OK but  
redundant.  This is where Walter's idea differs.  And I think it makes  
sense, when a base class has a virtual call, the overwhelming default is  
to continue the virtual chain.

So when answering the original questions [optional]:

1 = yes, 2 = yes, use override [virtual]
1 = no*, 2 = yes, use virtual
1 = yes 2 = no, use override final
1 = no*, 2 = no, use [final]

* note: if no base class virtual function exists, then the answer to  
question 1 is always no, and override is an error.

The one deviation from the current "require override" behavior of the  
compiler exposes the following sequence:

1. Base class does not define foo, derived class defines foo, virtual or  
not.
2. Base class adds foo as virtual

Currently, this will cause an error in the compiler.  With this new  
scheme, the compiler silently accepts this as two unrelated functions,  
because override is not used.  Arguably this is the correct choice, it is  
what the author of derived originally intended, and C# implies this by  
compiling, but it does give a warning.

Since we would have no keyword to indicate "non-overriding", a warning is  
not possible, since there's no explicit way to say "I'm not overriding".   
I would argue that putting 'new' there doesn't add much, you are unlikely  
to change your method's semantics to match that of the base class' new  
method.  What the C# explanation I quoted seems to miss is that it's not  
the author of the derived class who is affected, it's the USER of the  
derived class.  The confusion is for usage, not semantics, and that can be  
a problem.

Admittedly, the case above should be rather rare.  Perhaps the compiler  
can have a switch which identifies all the places where functions are  
masked?  I would like to see the switch be configurable as to which  
packages to do this for.

-Steve


More information about the Digitalmars-d mailing list