Hacker News new | ask | show | jobs
by tialaramex 961 days ago
> C++20 is remarkably safe and concise if you take full advantage of the type system.

Against what sort of laughably low bar are you measuring to make C++ "remarkably" safe ?

This is a language which delights in deliberately adding more footguns, on the rationale that well, it's less safe so surely it'll be faster right? No need to measure, no need to investigate what actual performance optimisations might somehow be available if we allowed the dangerous behaviour, no, just mandate it and YOLO.

C++ 20 introduces std::span. Now, std::span is basically a slice type, Rust's [T], and to some extent it's remarkable that C++ didn't have a slice type, but that's C++ for you. What's fascinating is that in 2020 I remind you they standardized a type which deliberately has no safe way to use it. It was proposed as a safe type, and WG21 stripped out the safety on the rationale that now it's faster (see above) then rejected all attempts to add the usual half-arsed C++ safety features to the type now that it wasn't safe by default.

Let me quote a C++ proposal paper (this isn't some hit piece from Rust fanatics, it's a serious proposal to the ISO working group) P2821 on std::span:

"Ultimately, this becomes a stereotypical example of how C++ traditionally handles safety. this example gets to be pointed at for years/decades to come. All of this could have been avoided"

1 comments

You can replace almost everything in C++ with stricter implementations of your own design if you don't like the behaviors or guarantees of the standard/default implementation. Many people do because the language is very amenable to it and the codegen is usually optimal. Living entirely within the standard library and the constraints it imposes to support backward compatibility is a choice, not a requirement. The standard design is always going to be less than ideal for some subset of applications, it is an unavoidable tradeoff.

The metaprogramming facilities of C++ are strong enough now that there is little that can't be customized without macros in a way that is nearly transparent.

Depending on which STL you use, there may also be assertions you can enable, e.g. via defining _GLIBCXX_ASSERTIONS https://gcc.gnu.org/onlinedocs/libstdc++/manual/using_macros...
The "Eh, we'll just throw it away and build a new one" attitude in C++ is part of how you got into this mess. Slices are a vocabulary type, without one what can you do? Well of course you just pass raw pointers around. Huh I wonder why we're having so many safety problems in C++...