Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

What to do with C++ modules?

nibblestew.blogspot.com

Post reply on HN
Print view View original

71–80 of 269 posts

Re: What to do with C++ modules?

#71

Post by ozars »

diath wrote: post #23
holowoodman wrote: post #2

Why bother? The world seems to have moved on to Rust, C++ is only for legacy maintenance stuff anymore.

There are a number of areas in programming where I'd always choose C++ over Rust - gameplay programming, retained-mode GUI programming and interpreted programming languages to name a few have very complex circular memory models that are somewhat solvable with weak_ptrs or refs stored in member variables passed through constructors but would be absolutely obnoxious to deal with and get right with the borrow checker.

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...

Re: What to do with C++ modules?

#72

Post by lyu07282 »

feelamee wrote: post #62
lyu07282 wrote: post #53

Earlier quoted context omitted.

I couldn't even tell if you are joking. Rust is weird, its like a programming language people developed a parasocial relationship with. If a Twitch streamer was a programming language it would be Rust. Perhaps its just people being immature I don't know.

> I couldn't even tell if you are joking I'm thinking the same about your comment :D

It's a programming language with a fandom, isn't that odd? ^^

Re: What to do with C++ modules?

#73

Post by wakawaka28 »

modeless wrote: post #18

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 The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well:…

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.

Re: What to do with C++ modules?

#74

Post by wakawaka28 »

modeless wrote: post #61
throwawaty76543 wrote: post #37

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 Of course it was completely ignored. Did you expect the standards committee to enforce caching in compilers? That's just not its job. > The next major advance to be c…

Both zapcc and Fil-C could benefit from the involvement of the standards committee. While both are very compatible, there are certain things that they can't fully support and it would be useful to standardize small language changes for their benefit (and for the benefit of other implementations of the same ideas). Certainly more useful than anything else the standards committees have done in the past 10 years. They w…

The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products.

Of course, these tools are of interest to the broader C++ community. Thanks for sharing.

Re: What to do with C++ modules?

#75

Post by sour-taste »

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.

Re: What to do with C++ modules?

#76

Post by emtel »

epage wrote: post #59
emtel wrote: post #33

I did C++ for over 10 years, and now have been doing rust for about 4. On the whole, I like rust much better, but I really miss header files. Modules are horrible for build times. If you change an implementation (i.e something that would not normally involve editing a header) the amount of rebuilding that happens is crazy, compared to any C++ project that was set up with a minimal amount of care.

What was it about headers? In terms of rebuild performance in defining the interface vs implementation, there is interest in having rustc handle that automatically, see https://rust-lang.github.io/rust-project-goals/2025h2/relink...

That change sounds like a big improvement if they manage to do it!

Re: What to do with C++ modules?

#77

Post by emtel »

WalterBright wrote: post #47
emtel wrote: post #33

I did C++ for over 10 years, and now have been doing rust for about 4. On the whole, I like rust much better, but I really miss header files. Modules are horrible for build times. If you change an implementation (i.e something that would not normally involve editing a header) the amount of rebuilding that happens is crazy, compared to any C++ project that was set up with a minimal amount of care.

D modules are very fast. Many of our customers rely on D being way faster than C++ to compile.

How does D avoid the problem I described?

Re: What to do with C++ modules?

#78

Post by modeless »

wakawaka28 wrote: post #74
modeless wrote: post #61

Earlier quoted context omitted.

Both zapcc and Fil-C could benefit from the involvement of the standards committee. While both are very compatible, there are certain things that they can't fully support and it would be useful to standardize small language changes for their benefit (and for the benefit of other implementations of the same ideas). Certainly more useful than anything else the standards committees have done in the past 10 years. They w…

The standards committee's job is not to develop products like software packages for free. It is to ensure that the language meets the requirements of stakeholders, many of whom develop competing commercial products. Of course, these tools are of interest to the broader C++ community. Thanks for sharing.

I'm not asking the standards committees to develop them for free. They were already developed! I'm saying that the committees should acknowledge their existence, and the fact that they solve some of C/C++'s biggest problems, in some ways better than the committee-blessed solutions. They deserve attention from the committees to direct language evolution in ways that support them better and encourage alternative implementations.

Re: What to do with C++ modules?

#79

Post by modeless »

wakawaka28 wrote: post #73
modeless wrote: post #18

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 The next major advance to be completely ignored by standards committees will be the 100% memory safe C/C++ compiler, which is also implemented and works amazingly well:…

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.

Re: What to do with C++ modules?

#80

Post by modeless »

jandrewrogers wrote: post #65
modeless wrote: post #34

Earlier quoted context omitted.

The catch is performance. It's not 200x slower though! 2x-4x is the actual range you can expect. There are many applications where that could be an acceptable tradeoff for achieving absolute memory safety of unmodified C/C++ code. But also consider that it's one guy's side project! If it was standardized and widely adopted I'm certain the performance penalty could be reduced with more effort on the implementation. An…

The design choices that make it slower can’t be mitigated either in theory or practice. C++ competes against other languages that make virtually identical tradeoffs that are far more mature and which have never closed that performance gap in a meaningful way. For the high-end performance-engineered cases that C++ is famously used for, the performance loss may be understated since it actively interferes with standard…

It won't ever be 1x the runtime, but if you think better than 2x is an insurmountable challenge then we will have to agree to disagree on that one. And for high-end performance engineering, I expect code that is aware of Fil-C could do better than naive code simply compiled with Fil-C.
Post reply on HN