On 11 April 2013 02:29, Minas Mina <minas_mina1990@hotmail.co.uk> wrote:
On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu
wrote:

On 4/10/13 7:30 AM, Manu wrote:
The _problem_ is that functions are virtual by
default. It's a trivial problem to solve, however it's a major breaking
change, so it will never happen.

I agree. We may as well save our breath on this one.

Hence my passing comment that spawned this whole thread, I see it as the
single biggest critical mistake in D, and I'm certain it will never be
changed. I've made my peace, however disappointing it is to me.

I disagree with the importance assessment, but am soothed by your being at peace.


Andrei

Why is virtual by default a problem?

Seriously? There's like 100 posts in this thread.

You could have non-virtual by default and would live happily
until a day where you forget to declare the base class destructor
virtual. Then you spent a lot of time trying to find why you are
leaking memory.

That's never happened to me. On the contrary, I'm yet to see another programmer properly apply final throughout a class...

In C++ you have to be aware all the time not to forget something
and screw everything. D is more forgiving, at a small cost of
performance.

'Small cost'? D is a compiled systems language, performance is not unimportant.
And how do you quantify 'small'? Scattered dcache/icache misses are the worst possible hazard.

So I don't buy the non-virtual by default argument. If your
profiler tells you that a particular virtual function is the
bottleneck, go on and make it final. That's why profilers exist.

Thanks for wasting my time! I already spend countless working hours looking at a profiler. I'd like to think I might waste less time doing that in the future.
Additionally, the profiler won't tell you the virtual function is the bottleneck, it'll be the calling function that shows the damage, and in the event the function is called from multiple/many places (as trivial accessors are), it won't show up at all as a significant cost in any place, it'll be evenly spread, which is the worst possible sort of performance hazard. Coincidentally, this called-from-many-locations situation is the time when it's most likely to cause icache/dcache misses!
It's all bad, and very hard to find/diagnose.

In C++, when I treat all the obvious profiler hot-spots, I start manually trawling through source files at random, looking for superfluous virtuals and if()'s. In D, I'm now encumbered by an additional task, since it's not MARKED virtual, I can't instantly recognise it, or reason about whether it actually should (or was intended to be) be virtual or not, so now I have to perform an additional tedious process of diagnosing for each suspicious function if it actually IS or should-be virtual before I can mark it final. And this doesn't just apply to the few existing functions marked virtual as in C++, now this new process applies to EVERY function. *sigh*

The language shouldn't allow programmers to make critical performance blunders of that sort. I maintain that virtual-by-default is a critical error.
In time, programmers will learn to be cautious/paranoid, and 'final' will dominate your code window.