81–90 of 174 posts
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. Unfortu…
It was when debugging a memory leak which occurred because I forgot to declare the base class destructor as virtual that I started to think C++ was a rather unfriendly language and not really designed to be easy to use. Then a few years later I read the spec for std::launder that I realised C++ was not really designed to be understood. It's a shame because it's actually a rather nice language in some ways. Here's hop…
Unfortunately the first example already re-uses one of the less good parts of C++, the "<<" operator for std::cout, which always was a bit of a hack (including strange order of operations since << normally is left shift)
> Because ++ and -- always have in-place update semantics, we never need to remember "use prefix ++/-- unless you need a copy of the old value." If you do need a copy of the old value, just take the copy before calling ++/-- I actually wish ++ and -- operators were removed. This would simplify everything, nothing to remember whether it's prefix or postfix operator, whether it copies something or not, you would just d…
Unfortunately, C++ uses ++ and -- for iterators, many of which cannot reasonably implement += or -=. This distinction is baked into the type system to tell whether or not an iterator supports efficient "multiple advance" (e.g. a linked list iterator doesn't have += but a pointer into a contiguous vector does). There's no way to fix this in a reverse-compatible way for existing code (which is one of the constraints of…
Is there any discussion or in-depth explanation of the syntax choices? I understand that a goal was context free unambiguous parsing. But there are some things that surprise me. For example, string interpolation: "Hello, (msg)$!\n" Why “(msg)$” and not “$(msg)”? Surely the latter is easier to parse?
https://github.com/hsutter/cppfront/wiki/Design-note:-Captur...
Earlier quoted context omitted.
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.
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, th…
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.
Earlier quoted context omitted.
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...
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...
This is, admittedly, a pretty niche case but certainly not inconceivable.
Earlier quoted context omitted.
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...
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.