Slow performance compared to C++, ideas?

[Declan]

On Tuesday, 4 June 2013 at 00:19:39 UTC, Manu wrote:
> 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

+1