Earlier quoted context omitted.
I would suggest to go through https://github.com/AnthonyCalandra/modern-cpp-features ; it's quite clean.
Broken link
Remove the trailing semicolon https://github.com/AnthonyCalandra/modern-cpp-features
C++20, How Hard Could It Be
31–40 of 444 posts
Re: C++20, How Hard Could It Be
#32Is there a case for or against incrementally adopting Rust ?
Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
Don't worry your little brain about these silly things. Programming is hard, let's go (language) shopping instead!
Re: C++20, How Hard Could It Be
#33Writing Chromium grade C++ seems like a hard job with all these extrinsic rules and regulations to make it work
You'll see these kind of rules at every place that cares about their C++ codebase. It's just not a language like Java, C# or JS where you can throw stuff at the wall and it'll probably work out.
Anyone serious with TypeScript/JavaScript has many Eslint rules to keep the codebase sain.
Re: C++20, How Hard Could It Be
#34When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?
Yes to some extent, depends on how one wants to defend their paper at ISO, during the several voting sessions.
Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream.
Visual C++ is already there in C++20 and increasingly improving C++23 support as well.
Re: C++20, How Hard Could It Be
#35Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.
It generally does although they have made technically breaking changes in the past (e.g. `auto`). This is the first release I've used where they broke something in actual code I use because of the comparison operator changes.
However it was easy to fix and actually it was because whoever wrote it did it wrong. Google also found a breakage that was hiding a bug.
So maybe their new stance is "only break incorrect code"? I dunno. I feel like a small amount of breakage is reasonable anyway. Breaking change absolutionists are generally just being dogmatic, and haven't really thought through what zero breaking changes really implies.
E.g. in languages with introspection it technically means you can't change anything.
Re: C++20, How Hard Could It Be
#36Writing Chromium grade C++ seems like a hard job with all these extrinsic rules and regulations to make it work
You'll see these kind of rules at every place that cares about their C++ codebase. It's just not a language like Java, C# or JS where you can throw stuff at the wall and it'll probably work out.
Even for Java, C# and JS we do enforce such kind of rules, e.g. https://sonarqube.org
Re: C++20, How Hard Could It Be
#37When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?
Yes to some extent, depends on how one wants to defend their paper at ISO, during the several voting sessions. Even when they do, it is in prototype done by the paper's author, not necessarily something that you can merge right away into upstream. Visual C++ is already there in C++20 and increasingly improving C++23 support as well.
I wonder if a feature has been accepted that turned out to not be tractably implementable!
I work on Ruby compilers and people often suggest features that they don’t realise would be catastrophic for performance if implemented, or are sometimes literally impossible to implement.
Re: C++20, How Hard Could It Be
#38Is there a case for or against incrementally adopting Rust ?
Which of these things is Rust immune to? How stable is it over a 10, 15, 20 year life? How old can the code be that Rust compiler still compiles and links successfully and bug-free?
Rust does well on this front. There's a new release every 6 weeks, and majority of users jump on it straight away (to complete shock of everyone not used to it).
Rust has editions which keep old code working without any changes, even if you mix it with new code, even if you do it with macros. It has rustfix that automatically migrates majority of the old code.
Rust has a standard project layout, standard test runner, and a central code repository, which enables testing language releases against nearly all publicly available code (see "crater run").
The language itself is stricter, with the safe subset being free of UB, so there's less stuff to break to begin with. You can't suddenly use a moved-from object.
There's even "cap lints" feature that disables `-Werror` equivalent for dependencies, so that new lints don't break your builds.
Re: C++20, How Hard Could It Be
#39It's easier to say goodbye C++!
A full rewrite seems extremely expensive and long. I’m afraid C++ isn’t going anywhere in our lifetime.
Re: C++20, How Hard Could It Be
#40Earlier quoted context omitted.
Can't blame them. Modules are Microsoft sabotaging the standard so they can be the only conforming implementation, just like with the Office .doc format. Modules are unimplementable shite. They would be great if this was the first iteration of the language, but they're a nightmare to fit into the existing ecosystem. If they get support in open source compilers, we can look forward to at least one or two decades of a…
Yet, somehow the GCC folks manage to keep improving their modules support, slow and steady. If they were unimplementable, there wouldn't exist already two major C++ compilers supporting them to some degree. It is only clang with their module maps pseudo concept that keeps lagging, that and plenty of other C++20 features.
Implementable by compilers, sure. Implementable by the ecosystem at large, yes, over the course of several decades.
Edit: Also, module support better be 100% binary compatible between GCC and Clang, or it's worse than complete garbage.