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

101–110 of 189 posts

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

#101

Post by jmalicki »

jstimpfle wrote: post #98
jmalicki wrote: post #96

Earlier quoted context omitted.

In practice, C means you end up with generic data structures with pointers to what they contain, rather than being inline. You do see a lot of macro use to deal with this, but that is just primitive, non-typesafe metaprogramming, and it gets unwieldy enough that in practice, you see people add an extra pointer. This is why it gets slower.

If you need callbacks and generics, you're not writing performance code. 99% of code in the wild is comically inefficient and is doing the wrong thing, using way too generic data structures and algorithms for very concrete problems. C++ templates may be one way to make comically slow code faster by spending a lot of compile time. But it's often much quicker to just write straightforward concrete code that the compile…

If compilation is even more than 10% of the time it takes you to run your tests, you're probably not writing correct code. Compilation times don't even measure.

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

#102

Post by SuperV1234 »

mort96 wrote: post #92
SuperV1234 wrote: post #91

Earlier quoted context omitted.

It is kind of weird at first but the reason is that `std::vector` requires heap allocation and transient allocations are not allowed in `constexpr` contexts. The purpose of `std::define_static_array` is to promote the storage of the vector to static storage to eliminate the transient allocation issue, and so that the `template for` can work properly with it. See wg21.link/P3491

Is there a reason why `std::meta::enumerators_of`, a reflection feature that's surely almost exclusively going to be used in constexpr contexts, returns a value which doesn't work in constexpr contexts?

It works generally, but not with expansion statements. See section 3.2 here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p13...

It seems that this is being worked on, and eventually the `define_static_array` won't be needed anymore

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

#103

Post by shooly »

SuperV1234 wrote: post #56
shooly wrote: post #52

Earlier quoted context omitted.

... and where does that `to_enum_string` come from exactly? It doesn't seem to be built-in, which is the point of the parent comment.

It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms. You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.

What? No. Parent comment is comparing C++ to modern programming languages, showcasing how they provide commonly used utilities out-of-the-box instead of making every programmer re-implement them again and again and again and again and again.

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

#104

Post by mort96 »

SuperV1234 wrote: post #102
mort96 wrote: post #92

Earlier quoted context omitted.

Is there a reason why `std::meta::enumerators_of`, a reflection feature that's surely almost exclusively going to be used in constexpr contexts, returns a value which doesn't work in constexpr contexts?

It works generally, but not with expansion statements. See section 3.2 here: https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2025/p13... It seems that this is being worked on, and eventually the `define_static_array` won't be needed anymore

Just another example where C++ language features are incompatible with each other, to be fixed "in a later version" which may or may not happen. There are so many of those in C++. I desperately wish they'd just do it properly initially.

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

#105

Post by SuperV1234 »

shooly wrote: post #103
SuperV1234 wrote: post #56

Earlier quoted context omitted.

It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms. You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.

What? No. Parent comment is comparing C++ to modern programming languages, showcasing how they provide commonly used utilities out-of-the-box instead of making every programmer re-implement them again and again and again and again and again.

The parent comment is quite clear:

> Why do I have to be familiar with all those weird symbols just to do a trivial thing ?

And my answer demonstrates that you do not have to.

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

#106

Post by jstimpfle »

jmalicki wrote: post #101
jstimpfle wrote: post #98

Earlier quoted context omitted.

If you need callbacks and generics, you're not writing performance code. 99% of code in the wild is comically inefficient and is doing the wrong thing, using way too generic data structures and algorithms for very concrete problems. C++ templates may be one way to make comically slow code faster by spending a lot of compile time. But it's often much quicker to just write straightforward concrete code that the compile…

If compilation is even more than 10% of the time it takes you to run your tests, you're probably not writing correct code. Compilation times don't even measure.

So every time you compile, you run your test suite? I don't. And you trust that I have experience writing and compiling programs too...?

It should be a goal to keep rebuild times around 1 second (often not quite possible, but 3-5 seconds, even for full rebuilds, is often realistic). I edit, compile, run, edit, compile, run. Editing and running can often take as little as 1-3 seconds, and I sometimes do it dozens of times working in a row, working on a single improvement. That's why there is a 1 second rebuild time goal.

In practice I often work on codebases I don't fully control, but when the build times are excessively high, I will complain and try to improve. Build times longer than 10-15 seconds break the flow, they are a significant productivity hit. But they are quite common with C++ codebases (it can also be bad with C codebases by the way, but C++ is typically much worse because of templates and metaprogramming which is very slow).

> Compilation times don't even measure.

You must be joking. Do you even program?

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

#107

Post by Quekid5 »

vanderZwan wrote: post #95
SuperV1234 wrote: post #90

Earlier quoted context omitted.

This cost is not significant nowadays, it's the frontend/parsing time. You can also use `#pragma once` which works everywhere, is nicer, and technically needs less work by the compiler, but compilers have optimized for include guards since a long time ago. Some random measurements I found: https://github.com/Return-To-The-Roots/s25client/issues/1073

Yes, I've heard that before, but comments like this one in your linked issue still make me wonder: > at least for gcc and Visual Studio using #pragma once has a significant impact. The fact is, the compiler does not need to continue parsing the whole file when reaching a #pragma once. otherwise the compiler always needs to do it even if the include guard afterwards will avoid double processing of the content afterwar…

The overhead isn't zero, but with SSDs (and filesystem caches in the gigabytes these days) it's damn near insignificant in pure terms of opening files and such.

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

#108

Post by jmalicki »

jstimpfle wrote: post #106
jmalicki wrote: post #101

Earlier quoted context omitted.

If compilation is even more than 10% of the time it takes you to run your tests, you're probably not writing correct code. Compilation times don't even measure.

So every time you compile, you run your test suite? I don't. And you trust that I have experience writing and compiling programs too...? It should be a goal to keep rebuild times around 1 second (often not quite possible, but 3-5 seconds, even for full rebuilds, is often realistic). I edit, compile, run, edit, compile, run. Editing and running can often take as little as 1-3 seconds, and I sometimes do it dozens of t…

You run your code before running tests? IMO that's bad practice.

1 second, seriously? Even the Linux kernel is based on C, and it doesn't even have compilation times approaching that.

I guess I also work on a lot of big data projects, where getting results will take... 48 hours or so, so anything shorter than that is basically some sort of unit test or dry run... so in that context, compilation times do not even register on the things slowing me down.

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

#109

Post by shooly »

SuperV1234 wrote: post #105
shooly wrote: post #103

Earlier quoted context omitted.

What? No. Parent comment is comparing C++ to modern programming languages, showcasing how they provide commonly used utilities out-of-the-box instead of making every programmer re-implement them again and again and again and again and again.

The parent comment is quite clear: > Why do I have to be familiar with all those weird symbols just to do a trivial thing ? And my answer demonstrates that you do not have to.

> And my answer demonstrates that you do not have to

Then again - "where does that `to_enum_string` come from exactly?".

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

#110

Post by bluGill »

spacechild1 wrote: post #71
SuperV1234 wrote: post #33

Earlier quoted context omitted.

That is true, but on the other hand Modules were standardized more than 6 years ago. Promises and claims have been made for longer than that on how Modules would have improved compilation times and made everyone's lives easier. In 2026, I still have to see any real evidence of that, especially when PCH + unity builds are much easier to use (except on damn Bazel, which supports neither) and deliver great results. If a…

> it is fair to question if the problem is with the design/implementability of the feature itself. The module story is just insane. How was it possible to get such a big feature into the standard without any working reference implementation? Isn't this the requirement for standard proposals to get accepted? If I compare this with how they treated JeanHeyd and his #embed proposal, the difference is staggering. To me i…

There was in visual studio which has had it other than minor details.the real problem is tools are needed to make modules work and those needed a lot of work. The work was already partially there because it's the same work that Fortran needs which tools supported but there were just enough details different to be annoying. Fortran modules were something that were always an afterthought and when tools started realizing that this is going to be a big deal, they decided they had to do it right, which took a lot of time too.

Maybe you forget Hacker News of 10 years ago, but in 2015-2016, everyone was complaining C++ doesn't have modules and how awful it must be because they're not modules. Now that C++ has modules, they're complaining about how it has modules.

Post reply on HN