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

141–150 of 269 posts

Re: What to do with C++ modules?

#141

Post by TuxSH »

aw1621107 wrote: post #132
pizlonator wrote: post #84

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…

> The problem with C++ modules is that they are empirically inferior to headers and separate compilation units. 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 lif…

> That's the fundamental limitation of modules systems that supposedly prevents this scaling?

Not the person you're replying to but I can see a problem with some dependency chains.

Let's say you have: stdlib If you only precompile A.hpp (as is commonly done), the many .cpp files can be compiled in parallel once A.hpp is precompiled, and you get a nice speedup.

If on the other hand you need to precompile everything, then all these cpp files must wait on A, then B, then C to be precompiled

Re: What to do with C++ modules?

#143

Post by jhasse »

motorest wrote: post #138
agent327 wrote: post #126

Earlier quoted context omitted.

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

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

It isn't only about template code. zapcc speeds up compilation when there's no cache. I tried it 10 years ago and it really reduced build times from minutes to seconds. For full builds.

Re: What to do with C++ modules?

#144

Post by jhasse »

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…

I have a cpp file that takes 10 seconds to compile. I change one line. How does ccache help me in this case?

Re: What to do with C++ modules?

#145

Post by drwu »

j16sdiz wrote: post #137
drwu wrote: post #24

Earlier quoted context omitted.

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.

Last time I checked, MSVC don't want to implement C99/newer and instead focus on C++.

To be fair, MSVC has the most C99 stuffs. What is mainly missing for porting (my) programs is the native complex number. But we have Intel compiler for free on Windows, which is fully compatible with the C/C++ standard and produces faster binaries.

The C++ frontend of MSVC handles (the common) compiler-specific language extensions differently than the other compilers. Besides, its pre-processor behaves differently too. It is now good that there is a clang frontend for MSVC.

Re: What to do with C++ modules?

#146

Post by domenicd »

The standardization process here feels similar to what happened with JavaScript modules. Introduced in ES2015, but the language standard only had syntax and some invariants. It had no notion of how to load modules, or how they might be delivered, or how a program that had a module at its root might be started. But there was a similar urgency, of "we must have this in ES2015".

I made it one of my first projects after joining the Chrome team to fix that gap, which we documented at [1]. (This reminds me of the article's "The only real way to get those done is to have a product owner...".)

You could even stretch the analogy to talk about how standard JS modules compete against the hacked-together solutions of AMD or CommonJS modules, similar to C++ modules competing against precompiled headers.

That said, the C++ modules problem seems worse than the JavaScript one. The technical design seems harder; JS's host/language separation seems cleaner than C++'s spec/compiler split. Perhaps most importantly, organizationally there was a clear place (the WHATWG) where all the browsers were willing to get together to work on a standard for JS module loading. Whereas it doesn't seem like there's as much of a framework for collaboration between C++ compiler writers.

[1]: https://blog.whatwg.org/js-modules

Re: What to do with C++ modules?

#147

Post by foldr »

fuhsnn wrote: post #63
dgan wrote: post #32

Earlier quoted context omitted.

what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests

Latest version of Fil-C with -O1 is just around 50-100% slower than ASAN, very acceptable in my book. I'm actually more "bothered" by its compilation time (took roughly 8x time of clang with ASAN).

I’ve found Fil-C 0.670 to be around 30x slower than a regular build, with -O1 vs. -O2 not making much difference. Perhaps it is very dependent on the kind of code. IIRC the author of Fil-C (which I think is an incredible project, to be clear) wants it to be possible to run Fil-C builds in production, so I think the comparison to a regular non-ASAN build is relevant.

Re: What to do with C++ modules?

#148

Post by ninkendo »

fooker wrote: post #119
ReflectedImage wrote: post #95

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.

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

Re: What to do with C++ modules?

#149

Post by saagarjha »

fuhsnn wrote: post #63
dgan wrote: post #32

Earlier quoted context omitted.

what is this sorcery. I was reading HN for years, this is the first time I see someone brings up a memory safe C++. how is that not even on the headlines ? what's the catch, build times ? do I have to sell my house to get it? EDIT: Oh, found the tradeoff: hollerith on Feb 21, 2024 | prev | next [–] >Fil-C is currently about 200x slower than legacy C according to my tests

Latest version of Fil-C with -O1 is just around 50-100% slower than ASAN, very acceptable in my book. I'm actually more "bothered" by its compilation time (took roughly 8x time of clang with ASAN).

For debugging, sure. Address sanitizer is itself pretty slow.

Re: What to do with C++ modules?

#150

Post by ShinTakuya »

grg0 wrote: post #22
holowoodman wrote: post #11

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.

Game engines (the thing that C# runs on top of) are written in C++. As is the C#/.NET runtime. As is anything that requires careful management of memory for performance. Application code is perfectly reasonably written in managed languages, but not so for the things that run underneath.

There's nothing inherent about C++ that makes it more suited than Rust for game engines though, Rust supports careful management of memory too. Of course, nothing besides inertia (i.e. Libs, existing code, etc.). And that of course is more than big enough of a reason to stick with it.
Post reply on HN