Slow performance compared to C++, ideas?

Manu turkeyman at gmail.com
Mon Jun 3 16:32:25 PDT 2013


On 4 June 2013 02:59, Andrei Alexandrescu <SeeWebsiteForEmail at erdani.org>wrote:

> On 6/3/13 12:25 PM, Manu wrote:
>
>> You won't break every single method, they already went through that
>> recently when override was made a requirement.
>> It will only break the base declarations, which are far less numerous.
>>
>
> That's what I meant.
>
>
>  How can you justify the change to 'override' with a position like that?
>> We have already discussed that we know PRECISELY the magnitude of
>> breakage that will occur.
>> It is: magnitude_of_breakage_from_**override /
>> total_number_of_derived_**classes. A much smaller number than the
>> breakage
>> which was gladly accepted recently.
>>
>
> Well it's kinda too much relativism that the number of breakages is
> considered small because it's smaller than another number.
>
>
>  And the matter is far from trivial.
>>
>
> It is trivial. To paraphrase a classic: "I'm not taking away your ability
> to make everything final, you can type 'final:' as much as you like."


You read my posts where I illustrate how going virtual is a one-way ride
right?
You can safely change to virtual, but you can't go from virtual back to
final.
Aside from the performance hazards, and the empirical evidence from
watching C++ programmers use D, virtual-by-default has the dangerous
potential to lock you in to an awkward situation where you can never safely
make a change to fix something that should never have been that way in the
first place.

 In fact, if you think this is
>> trivial, then how did the override change ever get accepted? That is
>> most certainly trivial by contrast, and far more catastrophic in terms
>> of breakage.
>>
>
> That's a completely different issue, so this part of the argument can be
> considered destroyed.


Rubbish. A similar set of considerations apply, and there's an awful lot
more supporting this one in addition.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130604/cb9d9e8f/attachment-0001.html>


More information about the Digitalmars-d mailing list