Slow performance compared to C++, ideas?

Steven Schveighoffer schveiguy at yahoo.com
Thu Jun 6 10:11:30 PDT 2013


On Thu, 06 Jun 2013 11:40:18 -0400, Joseph Rushton Wakeling  
<joseph.wakeling at webdrake.net> wrote:

> On 06/06/2013 05:00 PM, Steven Schveighoffer wrote:
>> On Wed, 05 Jun 2013 21:14:08 -0400, Jonathan M Davis  
>> <jmdavisProg at gmx.com> wrote:
>>> 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.
>
> I see a potential problem with allowing 'final' on its own to mean  
> 'final and
> non-overriding', which is that if you _mean_ to override a function in  
> the base
> class, but put simply 'final' and not 'override', it will still be  
> accepted by
> the compiler -- and it may not be obvious that the override is not  
> taking place.

Yes, this is a departure from the current code, which doesn't allow this.

But it is a generalized problem, not specific to final.  It's basically  
the lack of a storage class for meaning "no, I don't want to override the  
function".  Note that final does NOT do this.  In fact, we don't have a  
way to do this now.

new could be that storage class, but I am cautious about it.  new has a  
position close to that context, for custom allocators.

Another storage class would complete the solution, and make intentions  
very easy to make obvious.  At that point, we could have a warning/error  
for under-specification.

And another note to make is that the case where you are 'hiding' a base  
final function isn't really a problem.  It's more when you are hiding a  
virtual function, that this becomes an issue.  More likely, when you are  
hiding a *new* virtual function, because it didn't exist when you wrote  
your code.

-Steve


More information about the Digitalmars-d mailing list