Trip report: Autumn ISO C++ standards meeting (Kona, HI, USA) | Hacker News Reader

Trip report: Autumn ISO C++ standards meeting (Kona, HI, USA)

herbsutter.com

44 pointsmatt_d26 comments

Reflections alone would be one of the most impactful additions. And in contrast to most others: very difficult to do otherwise. I'm a bit surprised by the sudden push after long phase where it seemed like they would never come.

Contacts: yes please. Variadic indexing is one of those things everyone writes their own helper for. But this standard facility is very welcome indeed.

Some additions seem a bit of of scope for the standard of a language that famously refuses to fix mistakes. So in weary about std::hive, networking, physical units.

And an underrated cherry is at the end: cleaning up those "ill formed, no diagnostic required" clauses in the standard. For those who don't know: there are things forbidden in the standard which the compiler is allowed to not tell you (because it's difficult for the compiler to prove it). In particular this is omnipresent in the constexpr world. Leading to silly redundant code that manually assets things to explicitly trigger the compiler to check for errors.

Apparently someone showed up to pick up the work regarding reflection.

However at least we already have a kind of poor man's reflection, with constexpr if + concepts + type traits.

As for the rest, I am also not a big fan, but until my favourite language runtimes and GPGPU tools switch to something else, C++ is part of the toolbox. No need to add even more layers.

Reflection will be a welcome addition whenever it arrives. On the other hand, whatever is standardize will be a profound disappointment compared to Circle C++.

Yeah, Circle is the only "Typescript for C++" alternative.

Circle... I hope he can do it. Sounds too good to be true everyone I read about it.

boost::pfr is also huge for reflection in C++. It leverages corner cases of the language and compilers but does so uniformly (works for MSVC, GCC, clang which is all that matters in 2023).

It allowed me to write for instance https://GitHub.com/celtera/avendish which keeps on giving. The last version even add automatic field name reflection which is huge: https://www.boost.org/doc/libs/master/doc/html/boost_pfr/tut...

Thanks for the hint, wasn't aware of it.

Wow, how does this even work? Can you share some hints?

https://www.reddit.com/r/cpp/comments/17rnuh6/comment/k8srx5...

With every mailing list, trip report, CppCon presentation, etc, C++ gives the impression of being simultaneously far too simple and far too complex. IMO, the language does suffer from the lack of any coherent vision. That said, I’m interested in how far the language can go before implementations start giving up. Furthermore, it would be interesting to see how much tooling could help to simplify the language.

While C++ is undoubtedly complex, keeping up with Python, Java or .NET world, in terms of language features, runtime changes, standard library, alternative implementations and key libraries on the ecosystem is not much easier.

Nowadays I get the feeling to need some kind of memory dump reload everytime I switch projects.

Well, yes and no. I don’t mean to single out C++, I actually do appreciate the language, but it is far more difficult to evolve than most languages. For instance, languages like Java/.NET/Python/etc have a far more “defined” place in the world of software, and they can optimize their languages around their niche. With C++ you have businesses that don’t really care about performance, but they have 50+ million lines of code they rely on, embedded folks, HPC/GPGPU, graphics/AV, CAD/CAM/CAE, application programmers, and people responsible for providing support for customers for all of those domains. It’s extraordinary difficult to propose anything that doesn’t step on someone’s toes.

Sure, yet the complexity depth is quite similar, regarding the amount of ecosytem and programming stack knowledge that doesn't fit on the brain, after 30 years of programming language history.

Honestly? Well written C++, IMO, should look like C, but with alien builtins from the future. Once C++ gets really good ad hoc memory & resource tracking, you still have the harder problem that resource acquisition is a performance suck — which is true with any language from machine code to MetaOCaml.

What a waste, than just stick with C.

There is a reason you get this impression.

C++, the unparalleled language for writing fast libraries, is a complex beast.

C++, the sort of decent language with footguns for using said libraries, is getting more and more simpler over the years.

C++ should be put out to pasture along with asbestos and lead paint. It's unsafe at any speed and should be discouraged in favor of memory-safe alternatives. Evolving the language is a desperate attempt to stay relevant when it should not, in fact, stay relevant.

As should C. C++ is staying relevant (among other reasons) because it embeds C as a(n almost) subset in a natural way. To understand why C++ is remaining relevant, one must understand why C is remaining relevant. It has little to do with the language itself.

As long as the creators of other languages, including so-called C "successor" languages, keep giving zero shits about language interoperability and prefer to play in their little sandboxes that they've created for themselves instead of collaborating on creating a language-agnostic ABI, the C ABI will remain the ABI Franca, so C will stay relevant.

As long as C (and C++) are the only languages that you can compile and link the way you see fit as opposed to caving in to some my-way-or-the-highway language-specific "fully integrated" dependency manager and build system, C will stay relevant.

As long as this lack of vision, this pathological shortsightedness, and this complete disinterest in taking any steps whatsoever to unseat C from its privileged niche and create an ecosystem in which "successor" languages can compete with C on a level playing field continues to dominate the entire industry and every single "language" community in existence, C will stay relevant.

Heh, give snark, get snark. Virgil doesn't interoperate with C because ABI is a sticky, ugly, thorny thing. However, I've come to realize that several projects that want to use Wizard, a thing I wrote in Virgil, could do so if Virgil would link with C code. Problem is, all of that stuff at the C ABI layer is a quagmire.

I think pretty much all languages are hoping that that native ABI cesspool just disappears. I don't have a solution to that problem, but I know the solution isn't to keep on truckin' with uninitialized data, out-of-bounds-memory accesses, stack overflows, and undefined behavior. Surely we can do better.

The solution isn't to keep on trucking with the interoperability situation either, but you gotta fix that first. Or don't and keep on trucking with UB. Your choice. Y'all's choice.

Obviously I don't control the PL landscape's decision-making for what level of abstraction they want their compilers to target; that's why I helped create Wasm to put all of that mess into a sandbox so we can move on with a brighter future :)

Finally!

With the number of complex and obscure features that C++ has, it surprises me it has taken this long to implement such obvious features as "enum to string", and "insert a breakpoint here".

Very excited to see static reflection finally arriving! Also crossing my fingers for std::simd.

In the reflections example, is the "^" a new operator?

Yep, for types that's a new operator. It is also a binary operator for xor, for values. But no unary use from what I remember.They call it "reflection operator" in the paper.

It was previously used by Microsoft for their C++/CLR (or C++/CLI) to mark garbage collected values. But that was after the type, not in front iirc.

To quote the paper - "The reflection operator produces a reflection value from a grammatical construct (its operand)" [0]

[0]: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2023/p29...

Reply on news.ycombinator.com