Slow performance compared to C++, ideas?
Michel Fortin
michel.fortin at michelf.ca
Wed Jun 5 19:50:14 PDT 2013
On 2013-06-06 01:14:08 +0000, "Jonathan M Davis" <jmdavisProg at gmx.com> said:
> 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 think that it would be confusing for final to be implied if virtual is not
> used with override, and I'd argue that virtual should only go on the
> "introducing" one.
I concur. I don't think "override" and "virtual" should be allowed
together on the same function. Here's a few reasons.
Let "virtual" mean "create a new slot in the vtable". With that in
mind, "virtual override" makes no sense: you can't make a new vtable
slot and override it in the same class.
If the function is already virtual, there's much less to gain by making
it automatically final at the first override. It's very likely that it
can be overridden again safely, and it probably can't be optimized into
calling it statically most of the time since otherwise it wouldn't have
been made virtual in the first place.
There's also the consideration that adding/removing/reordering virtual
functions change the ABI, while doing the same for overridden function
does not. By only using "virtual" when allocating vtable slots, you're
making it easier to recognize changes which are likely to break already
compiled code.
P.S.: while implementing this change, please make sure private and
package functions can be virtual.
--
Michel Fortin
michel.fortin at michelf.ca
http://michelf.ca/
More information about the Digitalmars-d
mailing list