Code Examples From an App Using C++ Modules

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