181–190 of 269 posts
Earlier quoted context omitted.
if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?
The goal is to be able to import that 20yo battle-tested library into your C++20 codebase and it just works .
Earlier quoted context omitted.
That could be said of every additional c++ feature since c++0x. The committee has taken backwards compatibility, backwards - refusing to introduce any nuance change in favor of a completely new modus operandi. Which never jives with existing ways of doing things because no one wants to fix that 20 year old codebase.
No it can't be said for most other C++14+ features as they are actually implemented and used in real code bases.
Earlier quoted context omitted.
The goal is to be able to import that 20yo battle-tested library into your C++20 codebase and it just works .
Hyrum law would dictate that your C++20 now becomes C++11 or whatever is the oldest in the whole chain of dependency.
Earlier quoted context omitted.
Why should anyone use zapcc instead of ccache? It certainly sounds expensive to save all compiler's internal data, if that is what it does. I'm sure you must be aware, these compiler tools do not constitute a language innovation. I'd also imagine that both are not productions ready in any sense, and would be very difficult to debug if they were not working correctly.
Zapcc can, and frequently does, speed up the compilation of single files by 20x or more in the incremental case. CCache can't do that. And it's by far the common case when compiling iteratively during development. A speedup that large is transformational to your development workflow.
Earlier quoted context omitted.
> The sensible way to speed up compilation 5x was implemented almost 10 years ago, worked amazingly well, and was completely ignored. I don't expect progress from the standards committees. Here it is if you're interested: https://github.com/yrnkrn/zapcc Tools like ccache have been around for over two decades, and all you need to do to onboard them is to install the executable and set an environment flag. What value d…
ccache works at a translation unit level which means it isn't any better than just make-style incremental rebuilds when you aren't throwing away the build directory - it still needs to rebuild the whole translation unit from scratch if a single line in some header changes.
You used many words just so say "ccache is a build cache".
> it still needs to rebuild the whole translation unit from scratch if a single line in some header changes.
You are using many words to say "ccache rebuilds a translation unit when it changes".
What point were you trying to make?
Earlier quoted context omitted.
> C++ itself could never adopt for legacy reasons. I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born. C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate. Everything else is well on its way to be…
Concepts is a particularly hilarious example because what you got in C++ 20 is Bjarne's "Concepts Lite". Bjarne worked quite hard to get rid of the ideas and people behind the much more powerful C++ 0x Concepts, which resembles Rust's trait feature, and then it took a decade to land his worse alternative. That actually is a microcosmic survey of the problem with the language.
I agree.
Earlier quoted context omitted.
> C++ itself could never adopt for legacy reasons. I agree with your point except for the 'never' qualifier. It was certainly true when Rust was born. C++ has proven the 'never' part wrong multiple times. I think, by 2030, the only thing that C++ would lack that Rust has right now is the unified toolchain/packaging ecosystem because people are not going to settle that debate. Everything else is well on its way to be…
C++ can never change the way move vs copy semantics work, which is precisely the opposite of Rust’s. It’s the basis for rust’s ownership model, and it’s no small difference. Without this I don’t see how C++ can ever get a workable ownership model like Rust’s.
You are free to design your library in a way that your users only see one of these.
Earlier quoted context omitted.
Rust is basically the wanted fixes to C++ that C++ itself could never adopt for legacy reasons. So I'm afraid no by definition C++ can't adopt Rust's ideas because Rust's ideas were originally impossible C++ ideas.
Rust has been copying plenty of bad features from C++ too though.
While I can see compiler authors not wanting to have to turn the compiler into a build system, I'd really appreciate if they did do that. Having to create makefiles or other build artifacts is such a waste of energy for most applications.
Earlier quoted context omitted.
A lot of the problems with C++ are more foundational; you can't adopt the changes that newer languages have made, because that would be a new language - and we know this, because that new language's name is Carbon. There are things you can add , but the rot still permeates the foundations, and much of the newness goes partially unused because they're just not at home in C++. Use of `std::optional` and `std::variant`…
Ergonomics of std::optional and std::variant have nothing to do with bad foundations and all to do with the C++ committee insisting on these being library features rather than language features. I'm sure we will get the syntactic sugar eventually like we did get range-based for loops after having had to deal with macro approximations of foreach forever.
I have some hope that the upcoming compile time reflection will make it easier to implement said syntactic sugar.