Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Cost of enum-to-string: C++26 reflection vs. the old ways

vittorioromeo.com

Post reply on HN
Print view View original

161–170 of 189 posts

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#161

Post by jstimpfle »

SuperV1234 wrote: post #160
jstimpfle wrote: post #151

Earlier quoted context omitted.

Many C++ features are very slow to compile, especially templates. A quick compiling C++ project is most likely extremely conservative in its use of C++ (vs C) features.

That's just false. Templates are not slow to compile at all, and you can selectively pick TUs where they're instantiated. My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time. Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation. Most people still think that templates…

Erm... that's not just false. The point of templates is generic programming, reusable components. If you don't put them in a header, you're not reusing them much. And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times. You are refuting the very point you're making.

C++ templates _are_ slow to compile. They require running something like a dynamically typed VM in the compiler.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#162

Post by pjmlp »

vanderZwan wrote: post #157
pjmlp wrote: post #125

Earlier quoted context omitted.

That isn't going anywhere official. It is no different from any other language that compiles via C or C++ code generation, it got sold a bit differently due to his former position at WG21.

Well, if you mean "as an official C++ syntax" then I agree, and I suspect Sutter would agree as well. He labeled one talk about it a "Towards a Typescript for C++", after all[0]. But I do think it is different than other "compile to C++" languages, because it seems to be more of a personal case study for Sutter to figure out various reflection and metaprogramming features, and then "backport" those worked out ideas t…

What Herb Stutter misses on his Typescript and Kotlin for C++ metaphor is the actual reality how those languages integrate, unlike cpp2.

Typescript is a linter, nothing else, type annotations for JavaScript. The two features that aren't present in JavaScript, enums and namespaces, are considered design mistakes and the team vouched to focus only on being a linter,and polyfill for older runtimes, when possible (some JS features require runtime support).

While Kotlin spews JVM bytecode many language constructs, like co-routines, make it one way, it is easy to call Java from Kotlin, the other way around requires boilerplate code, manipulating the additional classes generated by the Kotlin compiler for its semantics.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#163

Post by w4rh4wk5 »

varispeed wrote: post #140
w4rh4wk5 wrote: post #136

Earlier quoted context omitted.

It's not that people are _still_ using debuggers; it's that people have actually discovered debuggers and workflows that are more productive than adding print statements, recompiling, and rerunning the program. Casey has been talking about this some time ago: https://www.youtube.com/watch?v=UzD_Ze6zFKA Also, John Carmack's perspective: https://www.youtube.com/shorts/PRE51epznT8

If you need to step with debugger, it means you are probably not understanding the code and cannot step through in your mind. Good test suite eliminates the need to debugger too.

Yeah, in my field this approach is pretty much infeasible.

Typically, I am given an ancient code base that is full of bad decisions, hard to read code and no tests in sight. Sometimes there are assertions, if I am lucky. It's impractical to create a reliably test suite, or rewrite everything from scratch.

Here, I heavily rely on a debugger just to make sense of the code. Sure, I'd wish that all of this code would just be sparkling clean, easy to read, free of UB, etc. But that's not the reality I work in, and good debugger is my number one tool getting the job done.

And don't even get me started on dealing with closed source implementations where all you could read is disassembly.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#164

Post by SuperV1234 »

jstimpfle wrote: post #161
SuperV1234 wrote: post #160

Earlier quoted context omitted.

That's just false. Templates are not slow to compile at all, and you can selectively pick TUs where they're instantiated. My entire VRSFML codebase compiles from scratch in ~4s and I liberally use C++ features, I just avoid the Standard Library most of the time. Templates are not inherently slow, people just don't know how to use them and don't know how to control instantiation. Most people still think that templates…

Erm... that's not just false. The point of templates is generic programming, reusable components. If you don't put them in a header, you're not reusing them much. And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times. You are refuting the very point you're making. C++ templates _are_ slow to compile. They require running…

Alright, I'll bite.

This is my `sf::base::Optional` template class, a lightweight replacement for `std::optional` with same semantics: https://github.com/vittorioromeo/VRSFML/blob/master/include/...

This is what ClangBuildAnalyzer reports:

  **** Template sets that took longest to instantiate:
     833 ms: sf::base::Optional (911 times, avg 0 ms)
Each individual instantiation of this class is sub 1ms. Including the header itself takes 3ms.

I'm sure I can optimize it even further if I wanted to.

---

Now to refute your other incorrect claims:

> The point of templates is generic programming, reusable components.

That's ONE use case. A more general use case is just reducing code repetition in a type-safe manner, which is extremely useful even within the same translation unit. Another use case is metaprogramming. And I'm sure I can come up with more. Templates are a versatile tool.

> And if you have to "selectively pick TUs where they're instantiated", you're basically admitting that you have to invest effort to reduce compile times.

...well, yeah? Of course you have to put in effort to reduce compile times. That doesn't undermine my point at all.

C++ templates are not slow to compile.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#165

Post by shooly »

SuperV1234 wrote: post #139
shooly wrote: post #109

Earlier quoted context omitted.

> And my answer demonstrates that you do not have to Then again - "where does that `to_enum_string` come from exactly?".

#include "to_enum_string.h" You don't have to understand it to use it. Even then, it's not that hard to understand, it just looks unfamiliar.

So finally, it's NOT built-in, and the parent comment was showing that in other languages - it IS built-in. So your code example is NOT correct and comparison is NOT correct, because you just hid the most important part of it, which is the implementation, that the user has to either: a) write themselves, b) find somewhere on the Internet.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#166

Post by shooly »

pjmlp wrote: post #126
shooly wrote: post #109

Earlier quoted context omitted.

> And my answer demonstrates that you do not have to Then again - "where does that `to_enum_string` come from exactly?".

A library that you install via vcpkg or conan. How many libraries do you read the source code after installing them with the package manager?

So it is NOT built-in and the code example shown above is dishonest - @SuperV1234 compares how "lean" two languages are but conveniently hides half of the code in their preferred language to make it seem simpler that it actually is, as otherwise it would look bad in the comparison!

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#167

Post by SuperV1234 »

shooly wrote: post #165
SuperV1234 wrote: post #139

Earlier quoted context omitted.

#include "to_enum_string.h" You don't have to understand it to use it. Even then, it's not that hard to understand, it just looks unfamiliar.

So finally, it's NOT built-in, and the parent comment was showing that in other languages - it IS built-in. So your code example is NOT correct and comparison is NOT correct, because you just hid the most important part of it, which is the implementation, that the user has to either: a) write themselves, b) find somewhere on the Internet.

So? The original argument was about the "ugly" syntax that the user didn't want to interact with nor read. I proved that there's no need to do so to consume reflection utils.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#168

Post by pjmlp »

shooly wrote: post #166
pjmlp wrote: post #126

Earlier quoted context omitted.

A library that you install via vcpkg or conan. How many libraries do you read the source code after installing them with the package manager?

So it is NOT built-in and the code example shown above is dishonest - @SuperV1234 compares how "lean" two languages are but conveniently hides half of the code in their preferred language to make it seem simpler that it actually is, as otherwise it would look bad in the comparison!

Reflection is built in, the support is there, anyone can make a left pad out such simple snippet.

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#169

Post by SleepyMyroslav »

psyclobe wrote: post #100
wat10000 wrote: post #75

Earlier quoted context omitted.

Why would I write a parser that almost-but-not-quite matches the compiler's own parser, when I could just use the compiler's parser directly? I don't want to write a parser, and I especially don't want to debug weird corner cases where my implementation diverges somehow. I just want to write some code that goes like, for each field in T, do X. C++ metaprogramming is bad, but the problem there is the C++ part, not the…

Cause its dead simple. Shell out, run a quick sed or something, then compile it in. It is quite amazing what 'magic meta' stuff you can do with that shit. Meanwhile 10 years in we are finally getting reflection.....

C++ is often cross compiled from mostly identical sources. Here is an example from Zig [1] that explains why it is not that simple.

1. https://matklad.github.io/2025/04/19/things-zig-comptime-won...

Re: Cost of enum-to-string: C++26 reflection vs. the old ways

#170

Post by shooly »

pjmlp wrote: post #168
shooly wrote: post #166

Earlier quoted context omitted.

So it is NOT built-in and the code example shown above is dishonest - @SuperV1234 compares how "lean" two languages are but conveniently hides half of the code in their preferred language to make it seem simpler that it actually is, as otherwise it would look bad in the comparison!

Reflection is built in, the support is there, anyone can make a left pad out such simple snippet.

> Reflection is built in

Can you quote the C++ standard section that specifically talks about the `to_enum_string` function?

Post reply on HN