Live data from Hacker News

C++ Modules Are Here to Stay

faresbakhit.github.io

91–100 of 143 posts

Re: C++ Modules Are Here to Stay

#91
post #60
post #29

C++ templates and metaprogramming is fundamentally incompatible with the idea of your code being treated in modules. The current solution chosen by compilers is to basically have a copy of your code for every dependency that wants to specialize something. For template heavy code, this is a combinatorial explosion.

I think that SFINAE and, to a lesser extent, concepts is fundamentally a bit odd when multiple translation units are involved, but otherwise I don’t see the problem. It’s regrettable that the question of whether a type meets the requirements to call some overload or to branch in a particular if constexpr expression, etc, can depend on what else is in scope.

This is one of those wicked language design problems that comes up again and again across languages, and they solve it in different ways.

In Haskell, you can't ever check that a type doesn't implement a type class.

In Golang, a type can only implement an interface if the implementation is defined in the same module as the type.

In C++, in typical C++ style, it's the wild west and the compiler doesn't put guard rails on, and does what you would expect it to do if you think about how the compiler works, which probably isn't what you want.

I don't know what Rust does.

Re: C++ Modules Are Here to Stay

#92

Earlier quoted context omitted.

import std; is an order of magnitude faster than using the STL individually, if that's evidence enough for you. It's faster than #include alone. Chuanqi says "The data I have obtained from practice ranges from 25% to 45%, excluding the build time of third-party libraries, including the standard library."[1] [1]: https://chuanqixu9.github.io/c++/2025/08/14/C++20-Modules.en...

Yeah, but now compare this to pre-compiled headers. Maybe we should be happy with getting a standard way to have pre-compiled std headers, but now my build has a "scanning" phase which takes up some time.

Modules are a lot like precompiled headers, but done properly and not as a hack.

Re: C++ Modules Are Here to Stay

#93

I can’t deploy C++ modules to any of the hardware I use in the shop. Probably won’t change in the near-to-mid future. It seems likely I’ll have to move away from C++, or perhaps more accurately it’s moving away from me.

Nobody uses all features of C++.

But you might not be able to use libraries that insist upon modules. There won't be many until modules are widespread.

Re: C++ Modules Are Here to Stay

#94
post #51

Earlier quoted context omitted.

> If you tools are not updated that isn't the fault of C++. It kinda is. The C++ committee has been getting into a bad habit of dumping lots of not-entirely-working features into the standard and ignoring implementer feedback along the way. See https://wg21.link/p3962r0 for the incipient implementer revolt going on.

Its happening again with contracts. Implementers are raising implementability objections that are being completely ignored. Senders and receivers are being claimed to work great on a GPU but without significant testing (there's only one super basic cuda implementation), and even a basic examination shows that they won't work well So many features are starting to land which feel increasingly DoA, we seriously need a l…

Please make one.

Re: C++ Modules Are Here to Stay

#96
post #28

Earlier quoted context omitted.

I don't think you're missing something. The standards committee made a bad call with "no submodules", ran into insurmountable problems, and doubled down on the bad call via partitions. "Just one more level bro, I swear. One more". I fully expect to sooner or later see a retcon on why really, two is the right number. Yeah, I'm salty about this. "Submodules encourage dependency messes" is just trying to fix substandard…

FWIW, Fortran does have submodules.

I suppose we shall amend to "The determined Real Programmer will fix FORTRAN" ;)

But, for the folks who didn't grow up with the Real Programmer jokes, this is rooted in a context of FORTRAN 77. Which was, uh, not famous for its readability or modularity. (But got stuff done, so there's that)

Re: C++ Modules Are Here to Stay

#97
post #29

C++ templates and metaprogramming is fundamentally incompatible with the idea of your code being treated in modules. The current solution chosen by compilers is to basically have a copy of your code for every dependency that wants to specialize something. For template heavy code, this is a combinatorial explosion.

The compiler is supposed to put the template IR into the compiled module file, isn't it?

Exactly, that's no better than #including transitive dependencies to compile large translation units.

Re: C++ Modules Are Here to Stay

#99
post #9

Earlier quoted context omitted.

And their code example doesn't actually return a value!

For main it's explicitly allowed by the standard, and no return is equal to return 0

which is super weird. If they can tell the compiler to allow no return, only for main, they can also tell it to pretend void return is int return of 0, only for main.

Re: C++ Modules Are Here to Stay

#100
post #61
post #28

Earlier quoted context omitted.

I don't think you're missing something. The standards committee made a bad call with "no submodules", ran into insurmountable problems, and doubled down on the bad call via partitions. "Just one more level bro, I swear. One more". I fully expect to sooner or later see a retcon on why really, two is the right number. Yeah, I'm salty about this. "Submodules encourage dependency messes" is just trying to fix substandard…

The C++ committee tries to do features with room for future extension. They believe that whatever you want from sub-modules is still possible in the future - but better to have a small (as if modules is small) thing now than try for perfects. We can argue about submodules once we have the easy cases working and hopefully better understand the actual limitations.

Just getting to this barely-working state took C++ longer than it took to create all of Rust, including a redesign of Rust's own module system.
Post reply on HN