Creator of LLVM, Clang, and Swift Says To Not Write Security Critical Code In C/C++

via Digitalmars-d digitalmars-d at puremagic.com
Tue Jul 14 04:01:12 PDT 2015


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.



More information about the Digitalmars-d mailing list