Slow performance compared to C++, ideas?
Manu
turkeyman at gmail.com
Mon Jun 3 09:16:33 PDT 2013
On 3 June 2013 18:11, deadalnix <deadalnix at gmail.com> wrote:
> On Monday, 3 June 2013 at 07:30:56 UTC, Kapps wrote:
>
>> On Monday, 3 June 2013 at 07:06:05 UTC, Manu wrote:
>>
>>> There are functions that
>>> the author intended to be overridden, and functions that have no business
>>> being overridden, that the author probably never imagined anyone would
>>> override.
>>> What if someone does come along and override one of these, and it was
>>> never
>>> designed to work under that circumstance in the first place?
>>> At very least, it will have never been tested. That's not a very robust
>>> API
>>> offering if you ask me.
>>>
>>
>> This is something just as important as the performance issues. Most of
>> the time people will leave functions to simply use whatever the default is
>> for virtual/final. If it's final, this works fairly well. The author hasn't
>> put in the effort to decide how to handle people overriding their function.
>> But with virtual by default, you don't know if the author actually
>> considered that people will be overriding the function or if it's simply
>> that they didn't bother specifying. I know the vast majority of my code is
>> virtual, simply because I didn't specify the 'final' keyword 500 times, and
>> didn't think about that I'd need to do it. The resulting code is unsafe
>> because I didn't consider those functions actually being overridden.
>>
>>
> The whole concept of OOP revolve around the fact that a given class and
> users of the given class don't need to know about its subclasses (Liskov's
> substitution principle). It is subclass's responsibility to decide what it
> override or not, not the upper class to decide what is overriden by
> subclasses.
>
Then OOP is fundamentally unsafe, because the author will never consider
all the possibilities!
If you want to create a class with customizable parts, pass parameters to
> the constructor. This isn't OOP what OOP is about.
>
Eh?
The performance concern is only here because things has been smashed
> together in a inconsequent way (as it is often done in D). In Java for
> instance, only overriden function are actually virtual. Everything else is
> finalized at link time.
Java is not compiled. If you compile Java code, all functions are virtual
always.
It's impossible in D with separate compilation, and dynamic libraries seal
the deal.
> Which is great because you are able to override everything when testing to
> create mock for instance, while keeping good performance when actually
> running the application.
>
I'm not taking away your ability to make everything virtual, you can type
'virtual:' as much as you like.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130604/bed9cbe6/attachment.html>
More information about the Digitalmars-d
mailing list