C++ build systems are typically based on file timestamps. Modifying a header file triggers recompilation of all translation units including that header.

There are workarounds like pimpl (aka. C style encapsulation). But this requires extra boilerplate and indirection. C++ modules might fix it at some point, but after 35 years of not having them in C++ most real life codebases aren't set up that way and may never be.

I don't think of pimpl as a tool for speeding up compilation, but for black box encapsulation.

If the compile time (when adding a method) is really an issue you can chop up and reconfigure your include files. A pain, but perhaps saves you time in the long run.

Of course (waves hands) modules will magically improve things...someday.

I think it can be both things.

Haven't you ever seen someone do

    struct Thing;
    struct OtherThing;

in lieu of just including "thing.h"? I see it frequently in real life code bases and I can't see a reason for it other than compilation time optimisation.

Sure, I do that all the time too. But you can't call a method (or look inside Thing, or pass it as an argument, only a pointer to it) without including the definition.

Hmm, there might be some interesting linker hacks to patch things up post compilation. But then you'd want some way to do the forward declaration for cases where Thing could have been passed in registers...

This is sometimes required to break dependency cycles. Also, you can use this to rearrange declarations in the same file.

Pimpl is both. I use it as black box also, but it does both things.

>>> 2. Poor encapsulation, adding private functions requires recompiling all dependents

>> under what circumstances does (2) hold?

To add a private member variable or function, you need to put it in the class definition in the header file. Then anything that includes the header needs to be recompiled.

Admittedly, adding a private member variable changes the object size and thus the ABI and thus requires recompilation of dependencies.

Thinking about that, is there any case in which private functions can end up in a vtable? In that case, it'd break ABI too.

> is there any case in which private functions can end up in a vtable?

Yes, but it generally isn't something that is done.

https://godbolt.org/z/5oPovKzoT

they don't need to be. dependents will continue functioning, because ABI hasn't changed

Now explain that to my build system.

But even if you managed to do that, first compilation is still much slower than it should be, because anlot of headers have to be included (transitively) to allow even declaring these fields and methods.

Adding private functions or fields requires changing the class declarations, which requires rebuilding any code that includes that class deckaration. It shouldn't be like that, especially for methods which shouldnt change anything about the class ABI.

Even worse, this dependency is transitive. Dependencies to allow defining these private methods an fields are exposed too, forcing inclusion of headers to all members of the class, even if it's only implementation details.

If you touch a header, even private only, includers will rebuild. Modules might fix this.