Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Mon Jun 3 17:19:26 PDT 2013


On 4 June 2013 03:06, David Nadlinger <code at klickverbot.at> 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<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.
>

Ah, sorry, I didn't realise that. I only recall conversations arising when
it actually became deprecated, and people had to change their code.

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 exact same path is available if you want to apply it:
 1. Introduce 'virtual', create a warning when override is used on a
function not marked. Functions remain virtual-by-default for the time being.
 2. At some later time, deprecate it (collecting the stragglers who haven't
updated their code yet). Functions remain virtual-by-default.
 3. Pull the pin. Functions become final by default, and virtuals should
have already been marked during the previous periods.

I'm not sure I follow your point about an isolated base class.
In the event you have an isolated base class, where no classes are derived
from it, then it's not actually polymorphic, so why should it's methods be
virtual?
In the event that it's a base-class-in-waiting, then it's true that you'll
notice a compile error at a later time when you do eventually derive from
it, but that's not really a breaking change, and it's almost in line with
my points about explicit consideration; each method that receives the
virtual keyword would take a moments consideration from the author as to
whether it's actually correct/safe to be overriding that method or not. Ie,
the momentary compile error where you write 'virtual' gives you the
opportunity for that thought.

>From DConf I know that you are actually are a friendly, reasonable person,
> but in this discussion, you really come across as a narrow-minded zealot to
> me. So, please, let's focus on finding an actually practical solution!
>

But this is a practical solution. The only counter-proposal I've heard is
Andrei's 'all methods use ufcs' idea, but I think that one would be a much
harder sell to the community. I'm certainly not convinced.

It's really quite trivial, it's orthogonal with usage of override, it's
more efficient, less error prone (which I have demonstrated happen all the
time), enhances interoperation with C++, and it should even improve code
fragility too (ie, people possibly overriding methods that are unsafe to
override where the author never considered the possibility).

Is there a reason this change offends you enough to call me names? Or can
you at least tell how I'm being narrow-minded?

For example, if we had !pure/!nothrow/!final or something along the lines,
> just mandate that "final:" is put at the top of everything in your style
> guide (easily machine-enforceable too) – problem solved?


That's not quite the case though. Even if I could retrain internal staff to
start doing that everywhere, you've potentially blocked access to a whole
bunch of libraries because library authors don't follow our style guide.
We suffer this in C++ all the time (see my many rant's about unnecessarily
spending my life re-inventing wheels). Anything to make subtle pushes that
improve usability/portability of libraries can only be a good thing.
Especially when library authors generally don't specifically consider all
usage environments. The language can assist some some extent.

It's also precisely the same amount of work to type 'virtual:' (and it's
the lesser common case to want to), except taking that angle enables the
advantages I mention above, and also tends to force people to give a
moments consideration to their API design/intent wrt virtual.
Remember going virtual is a one-way trip. It can never be undone, which
makes it a terribly dangerous default state.

And maybe it would even catch on in the whole D community and lead to a
> language change in D3 or a future iteration of the language.
>
> David
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130604/ce185ec3/attachment-0001.html>


More information about the Digitalmars-d mailing list