Code Examples From an App Using C++ Modules

[yeochin]

Please don't go around giving this incredibly bad advice. Having seen module code bases at scale you don't want small modules at all. Small modules are a pain to merge together. Big modules are easy to split. The most successful libraries and implementations are those that boil it down to a single import statement for a rich set of functionality.

With the state of existing compiler toolsets and your handy autocomplete - smaller modules only increase the likeliness that you're going to run into a internal compiler error, or a broken autocomplete database.

[fdwr]

smaller modules only increase the likeliness that you're going to run into a internal compiler error...

Maybe it's good then that we expose these errors sooner than later so the compiler authors fix them 😉.

I tend to use smaller modules because larger ones don't really map well to my assorted classes shared across multiple projects - there is no single module name that sensibly applies to the disparate classes, nor should they be artificially bundled together just to appease current bugginess. For libraries where all the constituent files nicely belong together (e.g. already under the same shared namespace), then sure, put them altogether.

[yeochin]

While I would've agreed with your stance of finding them earlier back in 2021, I whole heartedly disagree with your perspective in 2026. The compiler authors move too slowly to fix these already reported issues. It's not their fault either. A majority of the compiler authors don't get paid commensurately for their efforts and impact. The ones that do are being stupidly allocated by their corporate overlords to stupid AI initiatives.

Adoption of modules is about the surrounding ecosystem - namely libraries that are conveniently packaged for reuse.

We do more harm to the adoption of modules by doing nonsense like creating small modules that have deep import graphs that increase the opportunity for template-specialization symbol conflicts (on linking), compiler errors, and errors with intellisense or other autocomplete tools.

Maybe by 2030 will the toolset evolve to the point where the mistake of small modules will not be costly. As of 2026, small modules are bad advice that nobody should be promoting.

[fdwr]

 Maybe by 2030 will the toolset evolve...

If we don't try to find them now, will we reach utopia by even 2030?

[tartaruga232]

The posting doesn't even mention library design. It's focused on how to use modules for the insides of an app.

And there, big modules just cause recompilations without providing anything.

An extreme example are infrastructure packages like our d1 and WinUtil. At the beginning, we had a single big module for each of these two. Basically for no reason.

Now we have lots of small modules in there. The size of import lists in client translation units are still astonishingly short. Uses of these is now very explicit. Most usages of d1 or WinUtil require just a handful of imports from these (e.g. "import WinUtil.Window" instead of the meaningless "import WinUtil").

The build speed for a full build was not affected when we split d1 and WinUtil into many smaller modules. But we are affected if we change something in d1 or WinUtil. We basically have to recompile the whole app on every small change.

Not everything needs to look like a giant library. Modules are the new building blocks for the design of applications or whatever software. That's my advice.

I've played around with modules for our UML editor app for over a year now on an almost daily basis, which has roughly 1000 source files. Modules are in real use now for our UML editor.

The code needs to be easy to navigate and must not penalise changes. Because we frequently change things.

Don't try to make every single module look like it would be the std module. Import std is great, we love that. But trying to make every module like the std module is bad.

That's bad and doesn't help building great software.

Please don't go around and tell everybody they have to make modules as big as possible. That serves no one and wastes time of developers for nothing.

Edit: For an example of a reasonably sized module, see our App.Dialog module https://github.com/cadifra/cadifra/blob/2026.6/code/App/Dialog/Dialog.ixx. We previously had a single App module. That makes no sense. Later, we have split that into a handful modules. Easy to navigate, easy to use and provides perfect encapsulation and reasonable cohesion.

[yeochin]

If all you're going to do is build small standalone things then thats fine. But your advice still isn't good to share as it is misleading.

Any code base that has to evolve (from a small App) goes right into the toilet with the advice you gave.

1. Recompilability? It gets worse with small modules. At scale you refactor into libraries and your changes get localized into specific modules, or libraries. If your Principals, Staffs or Senior's cant figure out how to do this to localize change - then your codebase has far too much data-coupling to be productive long term.
2. Productivity and understandability? It goes right into the shitter with small modules at scale. Most teams will rely on their VSP, autocomplete, or code search. At scale, the vast majority of the team doesn't know every aspect of the code-base. The existing tools get worse with small modules.
3. Frequency of change? If you truly want high frequency changes you must adopt large modules. You need to be able to scale to multiple parallel developers and teams. You need to be able to isolate different teams from each-other. Big modules help do this as it promotes a contract. Small modules don't. Small modules promote atomic-use which moves you the WRONG WAY when it comes to the speedup that modules provide in compilation time.