41–50 of 444 posts
Is one release really causing so many problems? I thought C++ treated backwards compatibility as a holy thing.
Heck even Go folks are discovering their stable guarantee isn't as stable as they thought.
So, 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)
The valid use cases for it are ridiculously few.
It 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. ¯\_(ツ)_/¯
And theoretically clang has better ASM output in some cases I say theoretically, because it's been shown that GCC's "worse" ASM performs better; I'm not really an architecture aficionad, so I can't comment as to why that is.
Also, it's been a few years now since I did C/C++. So, maybe these are no longer the case.
Anyway, I've kinda pointed out what I like about clang over gcc, but I'd be curious what you prefer in gcc.
Earlier quoted context omitted.
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,…
How many editions are rustc, rust-gcc, cranelift and whatever might come, being still kept up to date in 40 years (C++ age)?
What about all the language changes that actually require semantic changes, how are epochs supposed to deal with inter-editions calls where the epochs have incompatible ABI expectations between caller and callee, regarded expected compiler behavior?
Earlier quoted context omitted.
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.
It is also written in a way that a linter should be able to detect if you disallow use after move.
https://source.chromium.org/chromium/chromium/src/+/main:com...
Earlier 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…
Earlier quoted context omitted.
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.
I stopped using C++ after lambdas were introduced (10 years ago or so?) Is there anything I can read to get up to date quickly?
It 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.
That said, when I explore weird edge cases in how differently Clang and GCC parse source code, and how differently they optimise it, in my experience Clang is still the more logical one, whenever there is a disparity, whereas the way GCC parses code and what code it produces is sometimes completely baffling (and that's not just optimisation stuff - without any optimisations enabled I encountered miscompilations a lot more with GCC than Clang).
I also consider C++ a language for mostly old projects. I start new ones in other languages and don't consider repeated rewrites every two standards, because the "modern c++" crowd found a new way to initialise variables, to be a good investment of my time.
It's easier to say goodbye C++!