On 12 December 2013 21:16, Dicebot <[email protected]> wrote: > 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. >
I feel quite the opposite, I would say that about C++ personally. I've built a C codebase from the ground over the course of a decade with ~25 programmers. It takes discipline, and a certainly sense of simplicity in your solutions. 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. 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? 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. > 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. 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. 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.
