Modern C++ Won't Save Us (2019)
alexgaynor.net
Modern C++ Won't Save Us (2019)
1–10 of 266 posts
Re: Modern C++ Won't Save Us (2019)
#2UB-invoking dereference in std::optional is such a baffling design choice.
The whole point of an optional type is to prevent accidental unchecked access to the value. Sure, sometimes it's useful for performance to skip the check when it's already known-safe from the context, but such dangerous optimization should have been behind a method like `beware_of_the_nasal_demons()`, not an innocent-looking convenience syntax for flirting with the UB — in a language that was supposed to be cleaning up the unsafety.
Re: Modern C++ Won't Save Us (2019)
#3It apparently didn't at the time either:
Modern C++ Won't Save Us - https://news.ycombinator.com/item?id=19723066 - April 2019 (388 comments)
Modern C++ Won't Save Us - https://news.ycombinator.com/item?id=19714204 - April 2019 (1 comment)
Re: Modern C++ Won't Save Us (2019)
#4no shit
Re: Modern C++ Won't Save Us (2019)
#5The deliberate omission of std::span::at() is annoying. The paper that introduced std::span was titled "span: bounds-safe views for sequences of objects," but there is actually no bounds checking in the standard. It's only true with debug builds that also use slow, debug versions of the STL, which have almost negligible value compared to just using sanitizers.
Re: Modern C++ Won't Save Us (2019)
#6UB-invoking dereference in std::optional is such a baffling design choice. The whole point of an optional type is to prevent accidental unchecked access to the value. Sure, sometimes it's useful for performance to skip the check when it's already known-safe from the context, but such dangerous optimization should have been behind a method like `beware_of_the_nasal_demons()`, not an innocent-looking convenience syntax…
> The whole point of an optional type is to prevent accidental unchecked access to the value.
You might argue it should be that, but it wasn't my impression that it is that. My impression was std::optional is just there to allow for representing the absence of a value. Ideally that should be zero-overhead, which means dereferencing it should degenerate into a normal object access. Hence the current design.
Re: Modern C++ Won't Save Us (2019)
#7It's interesting that one of the things C++ got right was having value semantics by default and most of these "problems" are the result of using either references or types that behave like dumb references/pointers such as std::string_view.
Re: Modern C++ Won't Save Us (2019)
#8> There are significant challenges to migrating existing, large, C and C++ codebases to a different language – no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try.
Um... no. Not every (or even most) existing large C/C++ codebase should be migrated to another language.
"But security vulnerabilities! And crashes!" I admit all that. But a program can be useful and therefore valuable, even if it crashes at times. Rewriting the program adds value only by removing crashes and exploitability. In many cases, that's effort that could be spent in more valuable ways.
Re: Modern C++ Won't Save Us (2019)
#9i love C++, C++ is the future of startups.
Re: Modern C++ Won't Save Us (2019)
#10> There are significant challenges to migrating existing, large, C and C++ codebases to a different language – no one can deny this. Nonetheless, the question simply must be how we can accomplish it, rather than if we should try. Um... no. Not every (or even most ) existing large C/C++ codebase should be migrated to another language. "But security vulnerabilities! And crashes!" I admit all that. But a program can be…
I read that sentence as applying to security-critical software. i.e., I don't think the author would insist that Quake II be rewritten in Rust.