31–40 of 174 posts
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)
Note that the "<<" operator for std::cout is not related to the language itself but related to the standard library.
Earlier quoted context omitted.
under what circumstances does (2) hold? for vanilla methods it's no problem
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.
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.
> 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…
But you would break the name! C++ would be a syntax error! I mean, there are people that already think that...
Cppfront, Herb Sutter's proposal for a new C++ syntax - https://news.ycombinator.com/item?id=32877814 - Sept 2022 (545 comments)
and also Cppfront: Autumn Update - https://news.ycombinator.com/item?id=37719729 - Sept 2023 (8 comments)
I wonder how this compares with Carbon -> C++ [0]. Carbon is (was?) a fantastic proposal, but not sure if it has lost steam since it was introduced or how well it is being adopted (be it inside Google or outside)? Being able to incrementally/interchangeably use/call existing C++ code (and vice versa) seems like a great design choice (in Carbon) without having to introspect the actual generated code. Not sure how easy…
I don't think anyone outside Google will seriously adopt this before it reaches v1.0. Even within Google, they may choose other options.
[0] - https://github.com/carbon-language/carbon-lang/blob/trunk/do...
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…
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.
Like Kotlin to Java Or ReScript to OCaml Or Gleam to Erlang
Kotlin is a distinct language with new features that (I'm fairly sure) make it non-isomorphic to Java code though. But I can't speak on the others.
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.
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...
Earlier quoted context omitted.
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.
Haven't you ever seen someone do
struct Thing;
struct OtherThing;
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…
Here's the source of C++'s vector class:
https://gcc.gnu.org/onlinedocs/gcc-4.6.2/libstdc++/api/a0111...
In comparison, vec in rust. (Note you need to scroll down a few pages to start seeing non-trivial functions. There's a lot of block comments.):
https://doc.rust-lang.org/src/alloc/vec/mod.rs.html#398
Or list in Go:
https://cs.opensource.google/go/go/+/master:src/container/li...
To my eye, that C++ code is by far the hardest code to read.