<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On 12 December 2013 21:16, Dicebot <span dir="ltr"><<a href="mailto:public@dicebot.lv" target="_blank">public@dicebot.lv</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On Thursday, 12 December 2013 at 09:01:17 UTC, Paulo Pinto wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Currently I always advocate that C and C++ development should<br>
always be done with warnings as errors enabled, coupled with<br>
static analyzers at very least during CI builds, breaking them if<br>
anything is found.<br>
</blockquote>
<br></div>
I literally can't imagine any large C project surviving any long<br>
without mandatory doing all listed stuff. It gets to state of<br>
unmaintainable insanity so fast.<br></blockquote><div><br></div><div>I feel quite the opposite, I would say that about C++ personally.</div><div><br></div><div>I've built a C codebase from the ground over the course of a decade with ~25 programmers.</div>
<div>It takes discipline, and a certainly sense of simplicity in your solutions.</div><div>I personally advocate C over C++ for this very reason, it emphasises simplicity in your solutions. It's impossible to get carried away and create the sort of unmaintainable bullshit that C++ leads to.</div>
<div>I like C, I just find it verbose, and prone to boiler plate, which has a tendency to waste programmers time... and what is more valuable than a programmers time?</div><div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">

That said, there are very different C projects. When I am<br>
speaking that coding C in D is less convenient than in C I don't<br>
mean some "normal" but performance-intensive application. I can't<br>
imagine anyone picking C motivated only by performance - it is<br>
more about being very controllable. Of course with modern<br>
optimizers C can no more be called "macro assembler" but it is<br>
still much much closer to that than D. To remove all "smart"<br>
side-effects in D you need to get rid of all druntime, avoid<br>
using some language features and resort to inline assembly<br>
relatively often. It is definitely possible and Adam has done<br>
some very nice job to prove it. But it leaves you with a very<br>
crippled language that does not even help you in sticking with<br>
that crippled subset. At this point you really start asking<br>
yourself - what does this give me over raw C to motivate the<br>
transition? So far I don't see anything convincing.<br>
</blockquote></div><br></div><div class="gmail_extra">I still consider C a macro assembler... I can easily (and usually do) visualise the asm output I expect the compiler to produce while I'm coding.</div><div class="gmail_extra">
If I'm writing performance intensive code, I am constantly disassembling and checking that the compiler is producing the code I am expecting. This feels normal to me.</div><div class="gmail_extra"><br></div><div class="gmail_extra">
What would you want inline assembly for in D? Inline assembly is almost always a mistake, unless you're writing a driver. You can't possibly schedule code better than the compiler. And in my experience, without breaking the ABI, I don't know any constructs I could produce manually in assembly that I can't easily coerce the compiler to generate for me (with better scheduling). Perhaps prefetching branch prediction hinting, which the compiler would typically require running a profile guided optimisation pass to generate, but there are intrinsics to insert those manually which don't interrupt the compiler's ability to reschedule the function.</div>
</div>