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

C++ Modules Are Here to Stay

faresbakhit.github.io

Post reply on HN
Print view View original

101–110 of 143 posts

Re: C++ Modules Are Here to Stay

#101

Post by starfreakclone »

Maxatar wrote: post #54
malfmalf wrote: post #53

Earlier quoted context omitted.

They are using modules in the MS Office team: https://devblogs.microsoft.com/cppblog/integrating-c-header-...

This is untrue. The MS Office team is using a non-standard MSVC compiler flag that turns standard #include into header units, which treats those header files in a way similar to precompiled header files. This requires no changes to source code, except for some corner cases they mention in that very blog post to work around some compiler quirks. That is not the same as using modules, which they have not done.

There's nothing non-standard happening there. The compiler is allowed to translate #include -> import. Here's the standardese expressing that: https://eel.is/c%2B%2Bdraft/cpp.include#10.

I do agree, it's not _exactly_ the same as using _named modules_, but header units share an almost identical piece of machinery in the compiler as named modules. This makes the (future planned) transition to named modules a lot easier since we know the underlying machinery works.

The actual blocker for named modules is not MSVC, it's other compilers catching up--which clang and gcc are doing quite quickly!

Re: C++ Modules Are Here to Stay

#102

Post by pklausler »

groby_b wrote: post #96
pklausler wrote: post #81

Earlier quoted context omitted.

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)

I'm so old, those jokes were about me.

Re: C++ Modules Are Here to Stay

#103

Post by pornel »

direwolf20 wrote: post #89
20k wrote: post #50

Earlier quoted context omitted.

Yes. Unfortunately the committee has completely abandoned safety at this point. Even memory/thread safety profiles have been indefinitely postponed. The latest ghost safety lifetimes thing is completely unimplementable There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transitio…

Using containers and std::string for everything eliminates the majority of safety bugs.

The safety bar is way way higher.

The C++ WG keeps looking down at C and the old C++ sins, sees their unsafety, and still thinks that's the problem to fix.

Rust looks the same way at modern C++. The std collections and smart pointers already existed before the Rust project has been started. Modern C++ is the safety failure that motivated creation of Rust.

Re: C++ Modules Are Here to Stay

#104

Post by pornel »

direwolf20 wrote: post #91
amluto wrote: post #60

Earlier quoted context omitted.

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…

Rust's generics are entirely type-based, not syntax-based. They must declare all the traits (concepts) they need. The type system has restrictions that prevent violating ODR. It's very reliable, but some use-cases that would be basic in C++ (numeric code) can be tedious to define.

Generic code is stored in libraries as MIR, which is half way between AST and LLVM IR. It's still monomorphic and slow to optimize, but at least doesn't pay reparsing cost.

Re: C++ Modules Are Here to Stay

#105

Post by direwolf20 »

pornel wrote: post #104
direwolf20 wrote: post #91

Earlier quoted context omitted.

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…

Rust's generics are entirely type-based, not syntax-based. They must declare all the traits (concepts) they need. The type system has restrictions that prevent violating ODR. It's very reliable, but some use-cases that would be basic in C++ (numeric code) can be tedious to define. Generic code is stored in libraries as MIR, which is half way between AST and LLVM IR. It's still monomorphic and slow to optimize, but at…

How does it handle an implementation of a trait being in scope in one compilation unit and out of scope in another? That's the wicked problem.

Re: C++ Modules Are Here to Stay

#106

Post by nickelpro »

luke5441 wrote: post #17
nickelpro wrote: post #11

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.

The OP does this and measures ~1.2x improvement over PCH.

Re: C++ Modules Are Here to Stay

#107

Post by AlotOfReading »

direwolf20 wrote: post #89
20k wrote: post #50

Earlier quoted context omitted.

Yes. Unfortunately the committee has completely abandoned safety at this point. Even memory/thread safety profiles have been indefinitely postponed. The latest ghost safety lifetimes thing is completely unimplementable There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transitio…

Using containers and std::string for everything eliminates the majority of safety bugs.

If only the standard differentiated between programs that are "mostly" free of UB and programs that aren't.

Re: C++ Modules Are Here to Stay

#108

Post by cataphract »

direwolf20 wrote: post #89
20k wrote: post #50

Earlier quoted context omitted.

Yes. Unfortunately the committee has completely abandoned safety at this point. Even memory/thread safety profiles have been indefinitely postponed. The latest ghost safety lifetimes thing is completely unimplementable There literally isn't a plan or direction in place to add any way to compete with Rust in the safety space currently. They've got maybe until c++29 to standardise lifetimes, and then C++ will transitio…

Using containers and std::string for everything eliminates the majority of safety bugs.

Not really. We keep getting pointer-like types like std::string_view and std::span that can outlive their referents.

Re: C++ Modules Are Here to Stay

#109

Post by amluto »

direwolf20 wrote: post #105
pornel wrote: post #104

Earlier quoted context omitted.

Rust's generics are entirely type-based, not syntax-based. They must declare all the traits (concepts) they need. The type system has restrictions that prevent violating ODR. It's very reliable, but some use-cases that would be basic in C++ (numeric code) can be tedious to define. Generic code is stored in libraries as MIR, which is half way between AST and LLVM IR. It's still monomorphic and slow to optimize, but at…

How does it handle an implementation of a trait being in scope in one compilation unit and out of scope in another? That's the wicked problem.

It’s impossible (?) due to the “coherence” rule. A type A can implement a trait B in two places: the crate where A is defined or the crate where B is defined. So if you can see A and B, you know definitely whether A implements B.

The actual rule is more complex due to generics:

https://github.com/rust-lang/rfcs/blob/master/text/2451-re-r...

and that document doesn’t actually seem to think that this particular property is critical.

Re: C++ Modules Are Here to Stay

#110

Post by on_the_train »

Night_Thastus wrote: post #18
on_the_train wrote: post #3

Earlier quoted context omitted.

It's been the go-to syntax for 15 years now

Go-to? I've never seen a project use it, I've only ever seen examples online.

It's still been the standard since c++11 and I've been using it every since in all teams I've worked in.
Post reply on HN