71–80 of 141 posts
Really sad to see such an influential computer scientist lose interest in advancing computing for the perceived slight against his legacy. Ironically I think Stroupstrup is actually doing more harm than good to his reputation by "evolving" C++ than simply putting it in maintenance mode and contributing to a modern language.
There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've…
> If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. My impression is this is not effectively true. It's not easy to follow all the rules of safe C++. I could be wrong but things like forgetting to use std::move in the right place or forgetting to use unique_ptr where you should. Putting member initializers in the…
Earlier quoted context omitted.
I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown l…
C++ is safe if you ignore most of its libraries and write everything from scratch, making safety your #1 priority, ahead of performance and everything else, and then doggedly stick to using nothing but the safe primitives you have created.
Even such basics as initialization is full of traps in C++, its truly language thats awful to produce anything safe with. C on the other hand isnt a bad language, but C's problem comes from the horrible standard library and bad standard. You can create much better C by passing -fno-strict-aliasing -ftrapv -fsigned-char to the compiler even now. Heck rust's unsafe is more unsafe than C. "C" could be improved with a be…
IMO the problem with C isn’t just the horrible standard library. It’s that you can’t make a better standard library — the language constructs needed to abstract almost anything don’t really exist.
https://github.com/Cloudef/zig-budoux/blob/master/src/c.zig#...
There's the language as idealized, and the language as used. Stroustrup is clearly brilliant, but he's talking about the former while everyone else means the latter. If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. That's, what, 0.1% of C++ projects? The rest of them use a soup of features and misfeatures that've…
> If you started a brand new C++ project today, using only the modern, safe ways of doing things and including only dependencies that do the same, OK, fine. My impression is this is not effectively true. It's not easy to follow all the rules of safe C++. I could be wrong but things like forgetting to use std::move in the right place or forgetting to use unique_ptr where you should. Putting member initializers in the…
You unquestionably shouldn't use C++ or Rust, you should use WUFFS to write this portion of the software, this way you get the absolute safely you presumably expect and also you get much better performance than you'd get from hand rolling say C++. You will need to write extensive test suites since the WUFFS tooling doesn't know what a BMP is so your testing is the only way to know you're decoding it correctly - but the safety property drops out of the language design, and while performance isn't magically guaranteed it's much easier to write small fast code in a language designed to help you do that and which also catches every safety mistake you make in the attempt.
Earlier quoted context omitted.
> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasona…
I've yet to see a valid scenario where C++ is superior to Rust, Python and Go. Use Python. If you need concurrency, then use Go. If you need even more performance, use Rust (using unsafe Rust only for the parts that need it). For the highest performance stuff, maybe consider C for critical parts only. C++ is not safe. It's a minefield of things that compile but are memory management mistakes. And then you're like "Lo…
The language has always been a dumpster fire. The best thing I can say about it is that is spurred development of many other languages to get away from it.
Earlier quoted context omitted.
But language and tooling can protect you from error classes, and when the error class (“memory safety”) factors in up to 70% of security vulnerabilities (by some estimates,) it makes sense to pay attention to tools which can protect you from those errors, rather than lament the lack of protection for the other 30% or errors, which, by the way, could have just as easily happened in a language without strong memory saf…
70% sounds a bit high but I can accept it. You can do a lot in regards to memory safety also in C / C++ : https://llvm.org/pubs/2006-05-24-SAFECode-BoundsCheck.pdf Anyway. Writing safe code in C is HARD but possible. Especially with good tooling. That is not to say everyone should use C. C is an exceptionally hard language to use safely and correctly and is not for everyone.
One meta-source for this is Prossimo[0]. They link to multiple vendor reports that range from 60 - 90%.
> Writing safe code in C is HARD but possible. Especially with good tooling.
I don’t disagree in theory, but I think it is so hard as to be impractical in almost every case. So, other than maintaining a legacy code base, why try at this point when other options are available?
0 - https://www.memorysafety.org/docs/memory-safety/#how-common-...
> Improving safety has been an aim of C++ from day one and throughout its evolution. Just compare the K&R C language with the earliest C++, and the early C++ with contemporary C++. My CppCon 2023 keynote outlines that evolution, C++ safety may have improved a lot, but it’s still far, far behind most other languages we use. It’s not even a close comparison. You throw a bunch of programmers at a problem and you will ge…
I admit I mostly don’t understand the “modern C++ is safe” argument. I maintain a decent size C++ code base, I try to use modern features in good taste, and I do think that C++ has added a lot of nice things. But nice != safe. basic_string_view is new in C++17. It sure beats pointers, but it’s a far cry from the kind of safety that you get in essentially any other language (except C): it is a reference with unknown l…
I a decade of writing C++ I never experienced dangling pointer bugs _until_ I started using string_view. Using it safely in multi-threaded environments is damn near impossible. I now don't let them escape the enclosing scope, and if I have to then I make a std::string from it.
Earlier quoted context omitted.
> The first step to solving a problem is accepting reality. Ok, the first thing I’d like to accept is that C++ is just not safe enough for most applications. And yes—you also can’t throw C++ in the garbage. Both of those statement are part of our reality—C++ is unsafe, and we will use it anyway. That’s why we solve this problem on two fronts. First, we advise programmers to ditch C++ for safer languages, when reasona…
I've yet to see a valid scenario where C++ is superior to Rust, Python and Go. Use Python. If you need concurrency, then use Go. If you need even more performance, use Rust (using unsafe Rust only for the parts that need it). For the highest performance stuff, maybe consider C for critical parts only. C++ is not safe. It's a minefield of things that compile but are memory management mistakes. And then you're like "Lo…
What makes me wary of jumping to Rust is the async stuff. From what I read, colored functions were introduced and most of the libraries that do useful stuff adopted async and kind of force you to be aware of it in your own code. For me, the perfect C++ replacement would be something like Go without the runtime burden. I'm not sure that this exists, so I use Go whenever I can and C++ in the ultra rare cases where I ca…
• an architectural limitation of JavaScript which Rust doesn't have (in Rust you can wait for an async result in a sync function, or run CPU-heavy code from an async function).
• a wish that languages had implicit magic that made sync and async calls look the same, which Rust intentionally doesn't want, because implicit magic is a terrible footgun in low-level code. It can be hidden in a high-level VM language that is in charge of all I/O, syscalls, and locks. But that is counter-productive for a low-level systems language for implementing I/O drivers, kernel syscalls, and custom locking primitives.
So Rust is "purple".
In reality Rust's async is awesome for what it is: a syntax sugar for state machines, which is able to flatten an entire call tree into a single fixed-size struct.
Most other async architectures need at least one allocation per async call or per await, but Rust needs one allocation per the entire call graph with any number of async calls and awaits.