131–140 of 269 posts
Earlier quoted context omitted.
C++ has a habit of incorporating all the best ideas from it's 'succcessor' languages once these ideas are mature.
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.
The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. The pre processor and linker, as derided as they are, allow for scaling of software size to extremes not possible with supposedly superior languages’ supposedly superior module systems. Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that…
I didn't think modules and separate compilation units are (completely) mutually exclusive? It's not like modules force you to use a single compilation unit for all your code; it just changes where the compilation unit boundaries/dependencies are (though to be fair I'm not entirely certain how much heavy lifting that "just" is doing)
> Want to build a >billion line of code OS? You can do that with headers and separate compilation units. Good luck doing that with any other tech
It's not immediately obvious to me why this must be the case. That's the fundamental limitation of modules systems that supposedly prevents this scaling?
Earlier quoted context omitted.
Rust does not solve any problem existing in expecienced C++ developer career. You dont write modern C++ code in such a way memory leak or dangling pointer is possible at all) This is exactly WHY we dont see a rush movement of C++ developers to Rust throwing away everything for Rust. Rust is trying to solve problems that already not exist 99.9999% of time in modern C++ code style and standards. Also, some day C++ comp…
Thinking that experience with C++'s many flaws will save you from running into them is delusional - just look at the number of CVEs in projects maintained by world-class C++ programmers. No amount of fallible human vigilance will stop you from forgetting the existence of a C++ quirk in the code you're rushing out before heading out for the night. Human oversight does not scale.
I bet there's easily tens of thousands of times more C++ code than Rust code out there.
Earlier quoted context omitted.
Rust has Arc and Weak that can be used for solving it in a similar way C++ does. The primary difference is forcing usage of Mutex to avoid a large class of data race issues IMHO, and that's what makes it harder to get right. Async in Rust is also more mature than C++ coroutines. So there's also that. https://play.rust-lang.org/?version=nightly&mode=debug&editi...
Rust doesn't have computed goto (gcc/clang extension heavily used in interpreters like CPython and LuaJIT for direct threading). You’re forced into function-call or jump-table dispatch, which tends to be slower.
On the other hand, there's the recently-added-to-nightly `become` for guaranteed tail calls, which might work better than computed gotos if CPython is a good example [0]
> When using both attributes [[[clang::musttail]] and preserve_none], Jin's new tail-call-based interpreter inherits the nice performance benefits of the computed-goto-based version, while also making it easier for the compiler to figure out optimal register allocations and other local optimizations.
To be fair I don't think Rust has a preserve_none equivalent yet, but given naked functions are a thing in Rust I'd hope it isn't too bad to support?
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.
if no one wants to fix this 20yo codebase, why is there someone who wants to push it to the new C++ standard?
Earlier quoted context omitted.
I believe with a little (okay a lot of) motivation and a solid LLM, these can all be rewritten faster than everyone says. Especially if it’s gradual. Mozilla and Dropbox did it. LLMs are good at translating between languages, and writing unit tests to make sure things still work the same.
How much Rust is actually in Firefox these days? The last numbers I see from 3 years ago is 10%.
12%. Assume the progress is linear (not logarithmic like most cases), we just need 60 more years to migrate those c/c++ code.
Earlier quoted context omitted.
There is a big big difference between C and C++. The article is about C++, which is being replaced by Rust imho. C is different, and far more frequently used for embedded or OS development. Don't know about games, but last I looked, stuff like unity was C#, so something else yet again.
It is a pitty that - GCC switched from C to C++ - CUDA switched from C to C++ But I can understand the decision, and at that time , C++ frontend features and libs were a little bit less horrible.
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…
> What value do you think something like zapcc brings that tools like ccache haven't been providing already? It avoid instantiating the same templates over and over in every translation unit, instead caching the first instantiation of each. ccache doesn't do this: it only caches complete object files, but does not avoid repeated instantiation costs in each object file.
I'm afraid this feature is at best a very minor improvement that hardly justifies migrating a whole compiler. To be blunt, it's not even addressing a problem that exists or makes sense to even think about. I will explain to you why.
I've been using ccache for years and I never had any problem getting ccache to support template code. Why? Because the concept of templates is ortogonal to compiler caches. It matters nothing, if you understand how compiler caches work. Think about it. You have the source file you are compiling, you have the set of build flags passed to the compiler, and you have the resulting binary.
That's the whole input, and output.
It's irrelevant if the code features templates or not.
Have you checked if the likes of zapcc is fixing a problem that actually doesn't exist?
My belief is that modules were designed for big tech companies that do massive builds parallelized across thousands of machines. Such an environment makes the complexity bearable and you get massive speedups from cached build artifacts. I think smaller companies and hobbyists kinda got screwed.
Modules provide more than just speed. Compile time benefits are great and the article is right about build-time bloat being the bane of every developer. But modules serve a deeper purpose. Explicit sub-unit encapsulation. True isolation. No more weird forward declarations, endlessly nested ifdef guards, or insane header dependency graphs. Things just exist as they are separate, atomic, deterministic and reliable. Mod…
> No more weird forward declarations
We c++ devs just have collectively accepted that this hack is still totally ok in the year 2025, just to improve build times.