Re:We used C++20 to eliminate a class of runtime bugs
by HALtheWise on Friday January 14, 2022 @02:47PM
(#29939375)
I've thought before about making a "dialect" of C++ that doesn't add any new fundamental capabilities, but simply changes syntax to make the more modern options easy and natural and make old C features verbose and difficult. For example, using "*" to represent unique_ptr and std::legacy_c_ptr<...> to represent "bare" pointers. Ideally, such a dialect could be fully include-compatible with all existing C++ code (although macros could be difficult), similar to how Rust "editions" or go "language versions" work. If C++ compilers offered a "#pragma modern_defaults" would people be interested in using it?
Re:We used C++20 to eliminate a class of runtime bugs
by pjmlp on Saturday January 15, 2022 @04:06AM
(#29944989)
Not really, one of the reasons people keep using C++ is its legacy.
It is already hard to educate people on modern language features and adoption of static analysers that enforce Core Guidelines.
Who would write the books and teaching materials for #pragma modern_defaults, and ensure it would be accepted into ISO?
Re:We used C++20 to eliminate a class of runtime bugs
by jcelerier on Saturday January 15, 2022 @03:16AM
(#29944747)
Actually in C++ the vast majority of the time, the right thing to do is
Foo foo{args};
I'd argue that in a language with the `new` keyword, nothing is more easy or natural than invoking it. `auto Foo = std::make_unique<Foo>(args);` is absolutely the right thing to do, but would you really be surprised to find `auto foo = new Foo(args);`?
I absolutely agree unique pointers are the right call. They just aren't necessarily the easy or natural call.
The contrast is rust where all ptrs are, by default, unique ptr and the compiler validates that for you.