Adding methods changes the vtable layout so there's no way to not recompile all the dependents. There's no solution to this unless private functions are guaranteed to not be virtual.
Of course, the elephant in the room is the C++ preprocessor. I haven't looked too closely into cppfront, but if I had the chance, I'd give the C macro system a bullet.
My favorite "macro" system by far is zig's comptime, which is beautiful and elegant. Zig code can simply elect to be executed in the compiler instead of at runtime. For example, here's how the print() function compiles in zig. Its a thing of beauty:
https://ziglang.org/documentation/master/#Case-Study-print-i...
Incremental compilation is fundamentally the same problem that web frameworks solve. There’s plenty of efficient ways to do it.
Well, yeah, that's the problem that modules are supposed to solve. (AFAIK the only fully C++20-standard-compliant implementation of modules is in MSVC, although even Clang modules are adequate for drastically reducing compile times.)
You are still going to have to recompile all your dependent compilation units if the vtable layout changes, as mentioned elsewhere, since all of your callsites have to reflect any changes to vtable lookups.
> My favorite "macro" system by far is zig's comptime, which is beautiful and elegant. Zig code can simply elect to be executed in the compiler instead of at runtime. For example, here's how the print() function compiles in zig. Its a thing of beauty:
How is this different from constexpr / consteval in C++?
std::format (introduced in C++20) is implemented in a similar fashion in that the format string is checked at compile-time (number of args, types, etc), so there's no good reason why C++ couldn't have a print function that behaves the same way and is validated at compile-time [0]. Libraries such Abseil and folly certainly provide this.
[0] It seems that C++23's std::print is not that function, oddly enough.
During release builds sure, optimize away with LTO and whatever is needed to make it vroom. During development, waiting several minutes for a minor private function update is just absurd.
There are also concerns about what you can link against or not once you modify the ABI of widely used types. This is of real concern at least for closed-source software or software that just cannot be recompiled.
I am not saying it should be the right choice, some of that software is legacy. I just say this is a real concern.
As for the private function. You can use a pimpl and use a private (on the cop file instead of header) and use that, for example, in many cases. This keeps compile time down.
All of them will result in incurring a performance penalty, either at the runtime, or at the start-up time, or in the compiler/linker, and memory blowouts. But it will solve the recompilation problem.
I too thought that sounded insane, so I just looked it up. I've been programming C++ for twenty five years and the thought of wanting to do this have never ever occurred to me...
This is, admittedly, a pretty niche case but certainly not inconceivable.
Making all virtual functions private is the better way to implement inheritance: it separates implementation from interface, allows for common functionality to be moved to the base class without requiring gymnastics in each and every derived class, and even lets you simplify the public interface to reduce compile times.
Try it, you'll like it. You may never go back to writing Java in C++.