On Tuesday, 14 July 2015 at 10:32:35 UTC, Walter Bright wrote:
Omitted from your comments are any mention of D's language support for purity and transitive const/immutability and @safe/@trusted/@system. These are critical for writing robust, encapsulated code. I know of no C++ sanitizers that attempt to address these.
Yes, if your codebase benefits from transitive const/immutability then that can simplify reasoning about the program.
I usually don't write code that way in C-like programming and prefer more fine-grained const to prevent myself from making encapsulation-related mistakes more than multi-threading issues etc.
In the ideal world I would want both. In the real world complexity is already higher by having const in the first place... so I understand the trade-off.
And lastly, writing code in C++ does not get you performance. Performance comes from careful balancing of algorithms, data structures, memory layout, cache issues, threading, and having intimate knowledge of how your particular compiler generates code, and then using a profiler.
Indeed. But you would not have written DMD in C++ if you did not need performance? That was more my point. C++ is not an attractive language if you can afford slower execution.
Languages like D and Go can stay interesting alternatives even when you can accept slower execution, but want strict typing and GC.
So for people who only want one language D has an advantage over C++, right there. (I don't really care, since I already deal with many languages every month.)
Have you used a profiler for your performance critical C++ code? You don't have to answer, but very, very few C++ programmers do. And I can guarantee you that those that don't use a profiler are not writing performant code (though they certainly may believe they are).
I basically don't care about raw throughput, but latency and meeting real time deadlines. Instrumentation can be useful… but I consider that "debugging".
My C/C++ bottlenecks are in tight loops with real time constraints on a single thread. Meaning, if it is too slow I will get dropped audio/video frames. So I write the code as fast as I conveniently can, taking heights for the possibility that I might have to go even lower level... (and hoping I don't have to). So I don't write optimal code from the get go. I try to write maintainable code first using "CPU independent simd" and decent cache-friendly layout.
Of course, a compiler is different since there are no latency issues, but throughput issues. Then you need to look at the whole call-tree using perf-counters etc.
But I think many situations where you need C/C++/D/Rust/Go are situations dominated by responsiveness/latency.
