6 ms·
C++ Modules Are Here to Stay
- whobre 8mo ago> auto main() -> int { Dude…
- on_the_train 8mo agoIt's been the go-to syntax for 15 years now
- Night_Thastus 8mo agoGo-to? I've never seen a project use it, I've only ever seen examples online.
- whobre 8mo agoSame here
- on_the_train 8mo agoIt's still been the standard since c++11 and I've been using it every since in all teams I've worked in.
- cpburns2009 8mo agoNow I haven't touched C++ in probably 15 years but the definition of main() looks confused: > auto main() -> int Isn't that declaring the return type twice, once as auto and the other as int?
- yunnpp 8mo agoNo. The auto there is doing some lifting so that you can declare the type afterwards. The return type is only defined once. There is, however, a return type auto-deduction in recent standards iirc, which is especially useful for lambdas. https://en.cppreference.com/w/cpp/language/auto.html https://en.cppreference.com/w/cpp/language/auto.html auto f() -> int; // OK: f returns int auto g() { return 0.0; } // OK since C++14: g returns double auto h(); // OK since C++14: h’s return type will be deduced when it is defined
- maccard 8mo agoI really wish they had used func instead, it would have saved this confusion and allowed for “auto type deduction” to be a smaller more self contained feature
- zabzonk 8mo agothe standard c++ committee is extremely resistant to introducing new keywords such as "func", so as not to break reams of existing code.
- maccard 8mo agoIndeed. I am a frequent critic of the c++ committee’s direction and decisions. There’s no direction other than “new stuff” and that new stuff pretty much has to be in the library otherwise it will require changes that may break existing code. That’s fine. But on the flip side, there’s a theme of ignoring the actual state of the world to achieve the theoretical goals of the proposal when it suits. Modules are a perfect example of this - when I started programming professionally modules were the solution to compile times and to symbol visibility. Now that they’re here they are neither. But we got modules on part. The version that was standardised refused to accept the existence of the toolchain and build tools that exist, and as such refused to place any constraints that may make implementation viable or easier. St the same time we can’t standardise Pragma once because some compiler may treat network shares or symlinks differently. There’s a clear indication that the committee don’t want to address this, epochs are a solution that has been rejected. It’s clear the only real plan is shove awkward functional features into libraries using operator overloads - just like we all gave out to QT for doing 30 years ago. But at least it’s standardised this time?
- CamperBob2 8mo agoIt's like calling a Ford Mustang Mach-E the "Model T++."
- few 8mo agoAnd their code example doesn't actually return a value!
- Davidbrcz 8mo agoFor main it's explicitly allowed by the standard, and no return is equal to return 0
- GrowingSideways 8mo ago[dead]
- direwolf20 8mo agowhich 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.
- webdevver 8mo agoi was sincerely hoping i could get auto main(argc, argv) -> int int argc; char **argv; to work, but alas it seems c++ threw pre-ansi argument type declarations out.
- zabzonk 8mo ago> c++ threw pre-ansi argument type declarations out they never were in C++.
- sethops1 8mo agoAs someone who quit c++ over 15 years ago it's been comical to watch what this language has become.
- rovingeye 8mo agoThis has been valid C++ since C++ 11
- direwolf20 8mo agoIt's unusual. Some, unusual, style guides require it. It's useful in some cases, even necessary in some which is why it was introduced, but not for simple "int"
- rovingeye 8mo agoit's literally the exact same thing. We use trailing return types to be consistent across the language.
- direwolf20 8mo agoWe use trigraphs to be consistent across the language.
- cocoto 8mo agoIn my opinion this syntax is super good, it allows to have all functions/method names starting at the same level, it’s way easier to read the code that way, huge readability improvement imo. Sadly nobody uses this and you still have the classic way so multiple ways to do the same thing…
- vitaut 8mo agoThis style is used in {fmt} and is great for documentation, especially on smaller screens: https://fmt.dev/12.0/api/#format_to_n https://fmt.dev/12.0/api/#format_to_n
- cmovq 8mo agoCan someone using modules chime in on whether they’ve seen build times improve?
- nickelpro 8mo agoimport std; is an order of magnitude faster than using the STL individually, if that's evidence enough for you. It's faster than #include <iostream> 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.html#how-much-compile-time-can-c20-modules-save https://chuanqixu9.github.io/c++/2025/08/14/C++20-Modules.en...
- luke5441 8mo agoYeah, 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.
- direwolf20 8mo agoModules are a lot like precompiled headers, but done properly and not as a hack.
- nickelpro 8mo agoThe OP does this and measures ~1.2x improvement over PCH.
- vitaut 8mo agoWe did see build time improvements from deploying modules at Meta.
- feelamee 8mo agowhy use modules if PCH on your diagram is not much worse in compile times?
- nickelpro 8mo agoMacro hygiene, static initialization ordering, control over symbol export (no more detail namespaces), slightly higher ceiling for compile-time and optimization performance. If these aren't compelling, there's no real reason.
- feelamee 8mo agoWe live with that for *decades*. For me this is not a daily problem. So yes, this is not compelling, unfortunately.
- bluGill 8mo agomodules are the future and the rules for are well thought out. Ever compiler has their own version of PCH and they all work different in annoying ways.
- WalterBright 8mo agoHaving implemented PCH for C and C++, it is an uuugly hack, which is why D has modules instead.
- w4rh4wk5 8mo agohttps://arewemodulesyet.org/ https://arewemodulesyet.org/ gives you an overview which libraries already provide a module version.
- srcreigh 8mo agoWow, the way this data is presented is hilarious. Log scale: Less than 3% done, but it looks like over 50%. Estimated completion date: 10 March 2195 It would be less funny if they used an exponential model for the completion date to match the log scale.
- w4rh4wk5 8mo agoYeah, my personal opinion is that modules are dead on arrival, but I won't waste my time arguing with C++ enthusiasts on that.
- ratmeadow 8mo agoNah I'm a C++ (ex?) enthusiast and modules are cool but there's only so many decades you can wait for a feature other languages have from day 1, and then another decade for compilers to actually implement it in a usable manner.
- w4rh4wk5 8mo agoI am fine with waiting for a feature and using it when it's here. But at this point, I feel like C++ modules are a ton of complexity for users, tools, and compilers to wrangle... for what? Slightly faster compile times than PCH? Less preprocessor code in your C++.. maybe? Doesn't seem worth it to me in comparison.
- ziml77 8mo agoI would think they don't want to hear that because of how badly they want modules to happen. Don't kill their hope!
- Kelteseth 8mo ago
- reactjs_ 8mo agoHere’s the thing I don’t get about module partitions: They only seem to allow one level of encapsulation. Program - Module - Module Partition whereas in module systems that support module visibility, like Rust’s, you can decompose your program at multiple abstraction levels: Program - Private Module - Private Module - Private Module - Public Module - Public Module Maybe I am missing something. It seems like you will have to rely on discipline and documentation to enforce clean code layering in C++.
- pdpi 8mo agoRust's re-exports also allow you to design your public module structure separate from your internal structure.
- groby_b 8mo agoI 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 engineering across many teams via enforcement of somewhat arbitrary rules. That has never worked in the history of programming. "The determined Real Programmer can write FORTRAN programs in any language" is still true.
- bluGill 8mo agoThe 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.
- groby_b 8mo agoNot to put too fine a point on it: The world has 35 years of experience with submodules. It's not rocket science. The committee just did what committees do. And sure, "future extension" is nice. But not if the future arrives at an absolutely glacial pace and is technically more like the past. This may be inevitable given the wide spread of the language, but it's also what's dooming the language to be the next COBOL. (On the upside, that means C++ folks can write themselves a yacht in retirement ;)
- TimorousBestie 8mo agoI 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.
- bluGill 8mo agoIf you tools are not updated that isn't the fault of C++. You will feel the same about Rust when forced to used a 15 year old version too (as I write this Rust 1.0 is only 10 years old). Don't whine to me about these problems, whine to your vendors until they give you the new stuff.
- Joker_vD 8mo ago> whine to your vendors until they give you the new stuff. How well does this usually work, by the way?
- krior 8mo agoNobody is "whining" to you. Nobody is mentioning rust. Your tone is way too sharp for this discussion.
- TimorousBestie 8mo agoIf C++ libraries eschew backward compatibility to chase after build time improvements, that’s their design decision. I’ll see an even greater build time improvement than they do (because I won’t be able to build their code at all).
- juliangmp 8mo agoMy experience with vendor toolchains is that they generally suck anyway. In a recent bare metal project I chose not to use the vendor's IDE and toolchain (which is just an old version of GCC with some questionable cmake scripts around it) and instead just cross compile with rust manually. And so far its been a really good decision.
- 8mo ago
- rienbdj 8mo agoFrom the outside looking in, this all feels like too little too late. Big tech has decided on Rust for future infrastructure projects. C++ will get QoL improvements… one day and the committees seem unable to keep everyone happy or disappoint one stake holder. C++ will be around forever, but will it be primarily legacy?
- 20k 8mo agoYes. 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 transition to a legacy language
- direwolf20 8mo agoUsing containers and std::string for everything eliminates the majority of safety bugs.
- pornel 8mo agoThe 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.
- AlotOfReading 8mo agoIf only the standard differentiated between programs that are "mostly" free of UB and programs that aren't.
- cataphract 8mo agoNot really. We keep getting pointer-like types like std::string_view and std::span that can outlive their referents.
- Night_Thastus 8mo agoThe fact that precompiled headers are nearly as good for a much smaller investment tells you most of what you need to know, imo.
- GrowingSideways 8mo ago[dead]
- fooker 8mo agoC++ 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.
- pjmlp 8mo agoIt has worked perfectly fine while using VC++, minus the usual ICE that still come up.
- fooker 8mo agoIt works perfectly when it comes to `import std` and making things a bit easier. It does not work very well at all if your goal is to port your current large codebase to incrementally use modules to save on compile time and intermediate code size.
- pjmlp 8mo agoOffice has made a couple of talks about their modules migration, which is exactly that use case.
- WalterBright 8mo agoD has best-in-class templates and metaprogramming, and modules. It works fine.
- amluto 8mo agoI 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.
- direwolf20 8mo ago
- yunnpp 8mo agoI recently started a pet project using modules in MSVC, the compiler that at present has best support for modules, and ran into a compiler bug where it didn't know how to compile and asked me to "change the code around this line". So no, modules aren't even here, let alone to stay. Never mind using modules in an actual project when I could repro a bug so easily. The people preaching modules must not be using them seriously, or otherwise I simply do not understand what weed they are smoking. I would very much appreciate to stand corrected, however.
- senfiaj 8mo agoI still hope that modules become mature and safe for production code. Initially I coded in C/C++ and this header #include/#ifndef approach seemed OK at that time. But after using other programming languages, this approach started to feel too boilerplate and archaic. No sane programming language should require a duplication in order to export something (for example, the full function and its prototype), you should write something once and easily export.
- kccqzy 8mo ago> No sane programming language should require a duplication in order to export something (for example, the full function and its prototype) You are spoiled by the explosive growth of open source and the ease of accessing source code. Lots of closed source commercial libraries provide some .h files and a .so file. And even when open source, when you install a library from a package from a distribution or just a tarball, it usually installs some .h files and a .so file. The separation between interface and implementation into separate files was a good idea. The idea seemed to be going out of vogue but it’s still a good idea.
- senfiaj 8mo ago> Lots of closed source commercial libraries provide some .h files and a .so file. I'm mostly talking about modules for internal implementation, which is likely to be the bulk of the exports. Yes, it's understandable that for dll / so files exporting something for external executables is more complicated also because of ABI compatibility concerns (we use things like extern "C"). So, yes header approach might be justified in this case, but as I stated, such exports are probably a fraction of all exports (if they are needed at all). I'll still prefer modules when it's possible to avoid them.
- up2isomorphism 8mo ago“C includes show it age.” But C++ is stating not because of there is a “++” there but because of there is a “C”.
- direwolf20 8mo agoDecades–old parts of the ++ also contribute.
- fasterik 8mo agoI get by without modules or header files in my C++ projects by using the following guidelines: - Single translation unit (main.cpp) - Include all other cpp files in main - Include files in dependency order (no forward declarations) - No circular dependencies between files - Each file has its own namespace (e.g. namespace draw in draw.cpp) This works well for small to medium sized projects (on the order of 10k lines). I suspect it will scale to 100k-1M line projects as long as there is minimal use of features that kill compile times (e.g. templates).
- indil 8mo agoI believe that's called a unity build. Really nice speedup.
- zabzonk 8mo agoSQLite calls this an "amalgamation". It is easy and convenient for users (not developers) of SQLite code. https://sqlite.org/amalgamation.html https://sqlite.org/amalgamation.html
- zabzonk 8mo agoThis might be OK for someone using your files (a bit like a header-only library) but not so great for team development.
- w4rh4wk5 8mo agoYou still organize the big file into sections to keep things together that are semantically related. For Git it mostly doesn't matter whether it's 100 small files or a single big one.
- jokoon 8mo agoI am curious to know if that 8.6x speedup is consistent. I don't see many "fair" benchmarks about this, but I guess it is probably difficult to properly benchmarks module compilation as it can depend on cases. If modules can reach that sort of speedup consistently, it's obviously great news.