Disable GC entirely

[Manu]

On 11 April 2013 02:29, Minas Mina <minas_mina1990 at 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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d/attachments/20130411/ad8e81a3/attachment.html>