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

161–170 of 269 posts

Re: What to do with C++ modules?

#161

Post by account42 »

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:…

> 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: https://github.com/pizlonator/fil-c

> It's not even possible to link to unsafe code.

This makes it rather theoretical.

Re: What to do with C++ modules?

#162

Post by account42 »

motorest wrote: post #97
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:…

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

Re: What to do with C++ modules?

#164

Post by imtringued »

TylerGlaiel wrote: post #49

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it". Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing i…

What do you mean by "no context can leak into it"? Do you mean it shouldn't export transitive imports?

As in `#include ` also performs `#include ` but `import vector` would only import vector, requiring you to `import iterator`, if you wanted to assign `vec.begin()` to a variable?

Or is it more like it shouldn't matter in which order you do an import and that preprocessor directives in an importing file shouldn't affect the imported file?

Re: What to do with C++ modules?

#165

Post by account42 »

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.

Why should anyone eat apples instead of oranges?

ccache doesn't add anything over make for a single project build.

Re: What to do with C++ modules?

#166

Post by account42 »

wakawaka28 wrote: post #103
modeless wrote: post #79

Earlier quoted context omitted.

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.

ccache speeds up compilation of single files by quite a lot, by effectively avoiding unnecessary recompilation. There are distributed caches that work like ccache too. Compiling a file for a second or fiftieth time with no changes because of doing a clean build is the absolute most common case. Maybe zapcc does additional caching of compiler internal state, but I would have to look into it to see if it's actually goo…

ccache does not speed up compilation at all, in fact it slows it down. It only speeds up re-compilation of the same translation unit (as in, bitwise identical preprocessed source code) which is often not all that useful, especially when the local development rebuild use case is already covered by make.

Re: What to do with C++ modules?

#167

Post by ra1231963 »

j16sdiz wrote: post #136
flohofwoe wrote: post #129

Earlier quoted context omitted.

How much Rust is actually in Firefox these days? The last numbers I see from 3 years ago is 10%.

> https://4e6.github.io/firefox-lang-stats/ 12%. Assume the progress is linear (not logarithmic like most cases), we just need 60 more years to migrate those c/c++ code.

That was my point — with LLMs the progress would not be at the same slope as with people only.

Re: What to do with C++ modules?

#168

Post by imtringued »

Kelteseth wrote: post #140
StephenHerlihyy wrote: post #35

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…

Not sure why you are getting downvoted, but this alone would make me switch (Still waiting for Qt moc support): > 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.

The only thing that forward declaration buys you is avoiding to include a header, which is not that expensive in C, but thanks to templates something as innocent as including a header can become infinitely expensive in C++.

Re: What to do with C++ modules?

#169

Post by account42 »

reactordev wrote: post #50
TylerGlaiel wrote: post #49

All that the C++ committee needed to do was just introduce "import" as "this is the same as include except no context can leak into it". Would have been dirt simple to migrate existing codebases over to using it (find and replace include with import, mostly), and initial implementations of it on the compiler side could have been nearly identical to what's already there, while offering some easy space for optimizing i…

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.

Re: What to do with C++ modules?

#170

Post by [deleted] »

tsimionescu wrote: post #41
StephenHerlihyy wrote: post #35

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…

Use a feature that doesn't really work, after so many years, hoping compilers will actually make it work if people use it - seems like a disastrous plan. People have tried to use modules, and have generally found that they fail, and have dumped them. It's unlikely at this point modules in their current form will ever be anything but a legacy feature in C++. Maybe someday a new implementation will arise, just like noe…

[deleted]
Post reply on HN