Although QT is not a tiny framework, and I don't really know if modern C++ tools are really good enough for this sort of problem, since C++11 to 20 probably caused those tools to explode in memory consumption
But I am not surprised at all. I remember around 2013, I would use bullet physics and the Ogre3D engine, and I had to tell visual C++ to increase its memory capacity because the compiler would refuse to continue.
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.
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++.
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.
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.
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.
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.
Haven't you ever seen someone do
struct Thing;
struct OtherThing;
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...
>> 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.
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.
Yes, but it generally isn't something that is done.
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.
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.
1. Very slow compilation.
2. Poor encapsulation, adding private functions requires recompiling all dependents, see (1).
3. Comically huge symbols make debugging much harder than it needs to be -- today gdb OOM'd my 16GB laptop when trying to form a backtrace of a typical QT application coredump.
Unfortunately it doesn't seem like cppfront can fix these issues. It may still be a worthwhile effort in other respects, of course.