101–110 of 395 posts
The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.
Why does static analysis not work here?
The C++ people are trying to refit ownership to the language without adding a borrow checker. This is painful. They've made it possible to write code that expresses ownership, but they can't catch all the places where the abstraction leaks. string_view is really a non-mutable borrow. But the compiler does not know this.
> but they can't catch all the places where the abstraction leaks. Why does static analysis not work here?
A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…
The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).
A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…
What legacy? It's not like there was a single "before time." There are problems coming up with all of it, because the underlying runtime model provides too few guarantees. We'll be plugging holes the rest of our natural lives.
An excellent example is std::unordered_map. This type was introduced to address perf problems with std::map. But unordered_map forces closed addressing, separate allocation, etc. which limit its performance. In return you get stronger iterator invalidation guarantees but these are rarely useful. Meanwhile Abseil's swiss tables, LLVM's DenseMap, etc. illustrate what a high-performance C++ hash table could be.
Any HN post mentioning C++ will inevitably be invaded by the Rust Evangelism Strikeforce.
Earlier quoted context omitted.
The problem, as far as I understand it (though I’m a layman), is that by the time the dead code optimization pass runs, the code has been transformed so much that there’s no obvious way for the compiler to tell the difference between “obvious programmer-intended null check that we shouldn’t optimize out” and “spurious dead code introduced by macro expansion” or (in C++) “by template instantiation”.
Couldn't user defined branches be tagged by such a compiler and if a tagged branch is eliminated the error generated with a reference to the tagged line in question?
A significant issue I have with C++ is that even if your code base is pure C++17, the standard library is a Frankenstein's monster of legacy and modern C++ mixed together that required many compromises to be made. A standard library that usefully showed off the full capabilities of C++17 in a clean way would have to jettison a fair amount of backward compatibility in modern C++ environments. I've noticed that more an…
I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).
Question - How does one write microcontroller code (or other memory-mapped I/O code) using a memory-safe language?
Tradeoffs. Ada has a history on microcontrollers, and is old enough we can answer with some certainty. You may end up having to bypass bottlenecks caused by runtime checks... And that means unsafe code in a critical location. Performance or safety. At different parts of your code you may find yourself choosing.
Earlier quoted context omitted.
I don't see the problem. You are free to use such a modern library (Google does, it's called absl). The good thing here is that the standard library doesn't require 'magic' to be implemented (unlike Swift where the standard library relies on hidden language hacks).
Sure it's possible to use a non-standard "standard library". But at that point you're already halfway to using a different language so why not consider switching from C++ to D / Rust / Go?
Languages exist to allow you to define your own layers of abstractions. The language choice ideally reflects what abstractions are useful for your project.