Damn. May as well have used a language that isn’t released yet like Zig. That’s a ton of problems.
Um no. When I upgraded it was a few hours of work at most, for Google since its code base is extremely large maybe a few days to weeks.
C++20, How Hard Could It Be
21–30 of 444 posts
Re: C++20, How Hard Could It Be
#22Is 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?
Re: C++20, How Hard Could It Be
#23As expected modules are relegated to some later time ("will be its own experiment")
Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
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 mixed modules/headers mess in open source projects.
Re: C++20, How Hard Could It Be
#24When a new C++ feature is proposed does the proposer have to provide a reference implementation? How can features be missing from the major compilers?
Re: C++20, How Hard Could It Be
#25Damn. May as well have used a language that isn’t released yet like Zig. That’s a ton of problems.
Um no. When I upgraded it was a few hours of work at most, for Google since its code base is extremely large maybe a few days to weeks.
Probably no big issue for a small to medium codebase. But I doubt the "just a few days" estimate for something as big as a web-browser. If I read correctly they even found use-after-move bugs during the process.
Re: C++20, How Hard Could It Be
#26Re: C++20, How Hard Could It Be
#27So, it seems most problems are C++ making things extra bureaucratic and annoying. Cool
The "pre/post increment of volatiles is deprecated" sounds like a huge pain. I can't imagine a worse waste of developer time than fixing such a minor thing (and to be fair C allowing both a++ / ++a should never have existed)
Re: C++20, How Hard Could It Be
#28It is so ironic, that now that Apple and Google decided to focus on their own language stacks, the C and C++ compiler vendors that profit from clang's license aren't that keen in making the upstream work for catching up with ISO C++. Thus making the once famous clang having an honorable third place in ISO C++ compliancy. Seeing this from a Google team makes it even more ironic.
gcc is better than clang on every metric. Sorry, it's the facts. ¯\_(ツ)_/¯
Re: C++20, How Hard Could It Be
#29Earlier quoted context omitted.
Thanks clang lagging behind ISO C++, you can use them today on Visual Studio 2022.
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.
Re: C++20, How Hard Could It Be
#30Writing 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.
> Java, C#
Maybe.
> JS
Hell no. "Frameworks" like React or Vue exist solely for the purpose of retaining developer sanity in the face of unregulated JS code.