[colonwqbang]

Most of my personal issues aren't with C++ syntax as such (although it also has many problems). My main gripes are:

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.

[jokoon]

I laughed at (3)

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.

[a_t48]

3) is forcing me to incorporate a symbol strip/upload to sentry piping at $WORK because Eigen debug symbols cause our build sizes to explode.

[MindSpunk]

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.

[josephg]

There isn't that much work the compiler should need to do. Ideally, a clever compiler could just update the vtables in some intermediate representation of the program and re-emit the binary. The C++ compiler today is so insanely wasteful - edit one header file and the compiler re-parses all the header files N^2 times. It should be possible to make a compiler thats way faster than any C++ compiler today.

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

[edflsafoiewq]

The problem is reflection, including SFINAE. Code can branch on if a method exists.

[josephg]

So? It shouldn’t take seconds to make one change to the reflection database. Or update derived code.

Incremental compilation is fundamentally the same problem that web frameworks solve. There’s plenty of efficient ways to do it.

[vitus]

> The C++ compiler today is so insanely wasteful - edit one header file and the compiler re-parses all the header files N^2 times. It should be possible to make a compiler thats way faster than any C++ compiler today.

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.

[Too]

In typical c++ manner, we can’t have nice things because {obscure internal technicality that don’t impact the user in any way whatsoever}$. As a user I don’t care what a vtable is. Just make it work. Other languages don’t have this 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.

[germandiago]

C++ is designed for good performance. Solving ABI problems permanently usually means an extra layer of indirection, which hurts performance.

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.

[inkyoto]

Yes, there are solutions, and the simplest one is replace the direct vtable lookup with an indirect one where the methods are referenced not by their numeric offsets in the vtable but via their symbolic names and the offset resolution is performed via a separate lookup table – not that dissimilar from how it is done in ELF shared libraries.

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.

[AnimalMuppet]

Um... isn't that guaranteed? What would it mean for a private function to be virtual? It can't be overridden by a different implementation in a child class...

[Findecanor]

Yes, you can have a private virtual member function, and it can be overridden in a child class (unless declared final), apparently.

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

[usefulcat]

It could make sense if you have a method that you want derived classes to be able to override but not to be able to call directly.

This is, admittedly, a pretty niche case but certainly not inconceivable.

[zetafunction]

Except the derived class can simply change the visibility of the override, so...

[AnimalMuppet]

TIL.

[zetafunction]

`final` prevents a child class from overriding a method. `private` does not.

[bregma]

Child classes can override private member functions in their parent class.

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

[PoignardAzur]

Wait, what? Virtual methods in C++ are opt-in. You only need the 'final' keyword when you're overriding a method in a child class.

[ThouYS]

under what circumstances does (2) hold? for vanilla methods it's no problem

[colonwqbang]

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.

[gumby]

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.

[colonwqbang]

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.

[gumby]

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

[DerekL]

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

[germandiago]

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

[jstimpfle]

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.

[phkahler]

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

[hkwerf]

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.

[NekkoDroid]

> 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

[ThouYS]

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

[jstimpfle]

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.

[loeg]

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

[jmac01]

How is dependency management not in this list hahaha holy crap c++ is so fucking shit to work with in this regard compared to another "modern" language.