<div dir="ltr">On 11 April 2013 02:29, Minas Mina <span dir="ltr"><<a href="mailto:minas_mina1990@hotmail.co.uk" target="_blank">minas_mina1990@hotmail.co.uk</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">On Wednesday, 10 April 2013 at 15:38:49 UTC, Andrei Alexandrescu<br>

wrote:<div><div class="h5"><br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
On 4/10/13 7:30 AM, Manu wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
The _problem_ is that functions are virtual by<br>
default. It's a trivial problem to solve, however it's a major breaking<br>
change, so it will never happen.<br>
</blockquote>
<br>
I agree. We may as well save our breath on this one.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hence my passing comment that spawned this whole thread, I see it as the<br>
single biggest critical mistake in D, and I'm certain it will never be<br>
changed. I've made my peace, however disappointing it is to me.<br>
</blockquote>
<br>
I disagree with the importance assessment, but am soothed by your being at peace.<br>
<br>
<br>
Andrei<br>
</blockquote>
<br></div></div>
Why is virtual by default a problem?<br></blockquote><div><br></div><div style>Seriously? There's like 100 posts in this thread.</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

You could have non-virtual by default and would live happily<br>
until a day where you forget to declare the base class destructor<br>
virtual. Then you spent a lot of time trying to find why you are<br>
leaking memory.<br></blockquote><div><br></div><div style>That's never happened to me. On the contrary, I'm yet to see another programmer properly apply final throughout a class...</div><div style><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">

In C++ you have to be aware all the time not to forget something<br>
and screw everything. D is more forgiving, at a small cost of<br>
performance.<br></blockquote><div><br></div><div style>'Small cost'? D is a compiled systems language, performance is not unimportant.</div><div style>And how do you quantify 'small'? Scattered dcache/icache misses are the worst possible hazard.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
So I don't buy the non-virtual by default argument. If your<br>
profiler tells you that a particular virtual function is the<br>
bottleneck, go on and make it final. That's why profilers exist.<br>
</blockquote></div></div><div class="gmail_extra"><br></div><div class="gmail_extra" style>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.</div>
<div class="gmail_extra" style>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!</div>
<div class="gmail_extra" style>It's all bad, and very hard to find/diagnose.<br></div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>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*<br>
</div><div class="gmail_extra" style><br></div><div class="gmail_extra" style>The language shouldn't allow programmers to make critical performance blunders of that sort. I maintain that virtual-by-default is a critical error.</div>
<div class="gmail_extra" style>In time, programmers will learn to be cautious/paranoid, and 'final' will dominate your code window.<br></div></div>