Inherent code performance advantages of D over C?

[Manu]

On 8 December 2013 03:29, Walter Bright <newshound2 at digitalmars.com> wrote:

> On 12/7/2013 1:52 AM, Joseph Rushton Wakeling wrote:
>
>> On 07/12/13 02:10, Walter Bright wrote:
>>
>>> I know well that people used to C++ will likely do this. However, one
>>> can get in
>>> the habit of by default adding "final:" as the first line in a class
>>> definition,
>>> and then the compiler will tell you which ones need to be made virtual.
>>>
>>
>> The disadvantage of this approach is that, if one forgets to add that
>> "final",
>> it doesn't just produce a performance hit -- it means that it may be
>> impossible
>> to correct without breaking downstream code, because users may have
>> overridden
>> class methods that weren't meant to be virtual.
>>
>
> D doesn't allow overriding non-virtual functions (unlike C++).
>

But, that's irrelevant, because if they did forget 'final' as suggested,
then everything is virtual, so your point has no foundation.

There is overwhelming (almost total) evidence that people barely use final,
either due to inexperience/ignorance, indifference, or forgetfulness. I
suspect those criteria probably cover close to 100% of the workforce.
It can't be the default state, there are no syntactic safeguards. You've
agreed on that in the past. Have you doubled back, or do you still agree?

People who make the sort of _conscious choice_ for their OOP library that
it should be the sort of java-like library where everything is overridable,
can easily type 'virtual:' at the top, and make their intent explicit.
There's no such simplicity with final, because unlike the 'everything is
virtual' case, where 'virtual:' is easily applicable and the compiler _will
produce an error message_ if they forget, there is no such useful concept
'everything is final', only 'most things are final', which means final must
always be micromanaged; 'final:' can't easily be used like 'virtual:' can.
And regardless, it remains prone to the risks in my second paragraph.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20131208/f5b3475f/attachment-0001.html>