Inherent code performance advantages of D over C?

Dicebot public at dicebot.lv
Thu Dec 12 03:16:06 PST 2013


On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:
> Currently I always advocate that C and C++ development should
> always be done with warnings as errors enabled, coupled with
> static analyzers at very least during CI builds, breaking them 
> if
> anything is found.

I literally can't imagine any large C project surviving any long
without mandatory doing all listed stuff. It gets to state of
unmaintainable insanity so fast.

That said, there are very different C projects. When I am
speaking that coding C in D is less convenient than in C I don't
mean some "normal" but performance-intensive application. I can't
imagine anyone picking C motivated only by performance - it is
more about being very controllable. Of course with modern
optimizers C can no more be called "macro assembler" but it is
still much much closer to that than D. To remove all "smart"
side-effects in D you need to get rid of all druntime, avoid
using some language features and resort to inline assembly
relatively often. It is definitely possible and Adam has done
some very nice job to prove it. But it leaves you with a very
crippled language that does not even help you in sticking with
that crippled subset. At this point you really start asking
yourself - what does this give me over raw C to motivate the
transition? So far I don't see anything convincing.


More information about the Digitalmars-d mailing list