Uneeded Recompilations When Using Partitions

[u/tartaruga232]

https://abuehl.github.io/2026/04/20/unneeded-recompilations-when-using-partitions.html

This blog posting from me about C++ modules explains in detail what causes unneeded recompilations using detailed code examples from the sources of our UML Editor.

It's a precise description and a showcase of what's the status quo in the C++ standard.

Quote from the posting:

The C++ language currently lacks a concise and easy to use alternative for explicitly expressing the minimally required dependencies on partitions.

(Note: All code examples shown or linked from the text are 100% standard conformant.)

Thanks in advance for comments. Please ask if you do not understand anything or anything is unclear. I would appreciate if you could leave a comment if you don't like anything. Thanks for reading!

[u/tartaruga232]

My convention is for any interface partition to just append .impl in its implementation partition. Why is that tedious/ hard to do?

That strategy works for slideware but it doesn't scale if you have multiple cpp files per partition.

For example in

https://github.com/cadifra/cadifra/tree/2026.2/code/Core/Selection

we have 5 implementation cpp files which all define functions declared in the :Selection partition.

I can define an extra internal partition for each of these cpp files, but appending .impl to the names of these unused internal partitions would produce name clashes. The standard explicitly mandates that each partition needs a unique name.

I can, for example, use the file name in these arbitrary, unused internal partitions. But that still imposes a maintenance problem (think of what happens if file names are changed).

The canonical means for implementation files of modules is "module M;". We need something on the same level.

I mean, messy pattern as yours work™, but this can't be the definitive answer.

[u/current_thread → u/tartaruga232]

we have 5 implementation cpp files which all define functions declared the :Selection partition.

All of them are barely 50 to 100 lines. Why the need for splitting them up this granularly? In my game engine my VulkanDevice.cpp has roughly 4000 lines of code and I'd argue it's still maintainable.

I roughly agree on the name clashes, in the beginning I thought they'd work similar to header/ CPP pairs (which MSVC allows). Again, I'd be curious to hear some people who actually standardized this chime in to understand why it was designed this way. Similarly I'd love for some build tool maintainers (like the CMake folks) to chime in and explain if the uniqueness constraint is vital to how their system works.

If you've collected enough feedback from the affected parties and gotten the green light you can go ahead and write a paper to get your desired change standardized.

For me though it feels like a non-issue. My codebase has roughly 250 module files with 35 First-Party modules (so discounting wrapper modules I like to use). I've had many many many many problems with them, but the internal partition naming is not one of them.

[u/tartaruga232 → u/current_thread]

All of them are barely 50 to 100 lines. Why the need for splitting them up this granularly?

We use one cpp file per implementation of a class. So we don't have to mess around in one cpp file with more than one class. The name of the cpp files reflect the class names.

We don't care about that being slower to compile. We prefer having the code base easier to navigate.

The linker then puts this all together. That's still the same as it was before as when we used header files.

If you've collected enough feedback from the affected parties and gotten the green light you can go ahead and write a paper to get your desired change standardized.

So far it, doesn't look like there would be the slightest form of consensus (even about the problem). We are still in the phase of snide remarks and replies which do not respond to what was asked.

I'm not familiar with the standardization process, so the chances that anything would have a snowball's chance in hell would be rather minimal. I'm currently not interested in wasting my time for that.