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

111–120 of 189 posts

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

#111

Post by bluGill »

SuperV1234 wrote: post #93
maccard wrote: post #60

Earlier quoted context omitted.

By that logic why would anything have to be standardised?

By your logic we shouldn't ever use external libraries. PFR has given us reflection since C++14. I also don't think the Standard Library is particularly well-defined nor well-implemented, as demonstrated by the atrocious compilation times.

The standard library shows the roots of the mid-1990s and there are a lot of things we would definitely do different today. However, it is still extremely well defined compared to most everything else. C++ is one of the few languages where the library actually guarantees how an algorithm works, which is both good and bad. The bad part is some things that made perfect sense in 1995 simply don't make sense in our modern CPUs where cache is important.

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

#112

Post by daemin »

vanderZwan wrote: post #85

> The header is the cost. Not the reflection. The reflection algorithm is fast – asymptotically ~0.07 ms per enumerator, essentially the same as the hand-rolled switch in the X-macro version (~0.06 ms). What makes reflection look expensive is : just including it costs ~155 ms per TU over the baseline. So speaking of old ways, I'm not a C++ dev, but a while ago saw someone comment that they still organize their C++ pr…

What I found (so far on MSVC) is that #pragma once does only process the file once, where as include guards still open the file each time it is included. Though it takes almost no time to do so but it still appears on the traces.

I'm going to experiment with other compilers and figure out how they handle it.

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

#113

Post by spacechild1 »

SuperV1234 wrote: post #94
spacechild1 wrote: post #86

Earlier quoted context omitted.

The implementation doesn't look too bad, but the usage is terrible: #define E_LIST(X) \ X(V0) X(V1) X(V2) X(V3) DEFINE_ENUM(E, E_LIST) That's not how I want to declare my enums...

To be honest there are ways to make that much nicer. I believe that if you use recursive macros using the VA_OPT feature, you should be able to provide enumerators directly to define enum as a list. The underlying machinery implementation is going to be much uglier and complex, though. See https://www.scs.stanford.edu/~dm/blog/va-opt.html

Oh, I didn't know about __VA_OPT__(), thanks for that!

That looks much nicer indeed, but I still vastly prefer the other solutions, simply because I can just declare regular enums.

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

#114

Post by spacechild1 »

bluGill wrote: post #110
spacechild1 wrote: post #71

Earlier quoted context omitted.

> 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 realizin…

I don't remember because I wasn't there :)

People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?)

As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all?

My point was: if you add such a big feature, shouldn't the standard require a sufficiently complete implementation? Otherwise, how can they assess whether the proposal actually works in practice and lives up to its promises?

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

#115

Post by LugosFergus »

mentos wrote: post #29

Curious to see if Epic Games ever refactors their reflection in Unreal Engine to use C++ 26 reflections or not.

That'll never happen. The engine's entire serialization system is built around their custom reflection layer and UHT. Not to mention how this would affect licensees. PLUS, they just laid off a bunch of people, and the leftovers are focused on Tim's Verse fiasco. I hate to use jargon here, but there's no "business value" to switching.

EDIT: and based on these compilation time results, this would be a major setback for building the engine, which already takes an eternity.

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

#116

Post by bluGill »

spacechild1 wrote: post #114
bluGill wrote: post #110

Earlier quoted context omitted.

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 realizin…

I don't remember because I wasn't there :) People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?) As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all? My point was: if…

Again, they had a sufficiently complete implementation. That implementation was in Visual Studio, clang had a very different implementation. The standard decided to take the Microsoft version. There are pros and cons to both and I will not fault the decision but either way one of the two had to lose and there is no surprise that for something complex it will take a long time to reimplement it to whatever the new standard is.

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

#117

Post by spacechild1 »

bluGill wrote: post #116
spacechild1 wrote: post #114

Earlier quoted context omitted.

I don't remember because I wasn't there :) People are not complaining about the fact that C++ has modules, but about their usability and effectiveness. The compile time benefits seem modest and I have seen reports that it breaks Intellisense. (Maybe that's not true anymore?) As Vittorio said, if it takes compiler vendors so long to implement them properly, maybe the design wasn't that good after all? My point was: if…

Again, they had a sufficiently complete implementation. That implementation was in Visual Studio, clang had a very different implementation. The standard decided to take the Microsoft version. There are pros and cons to both and I will not fault the decision but either way one of the two had to lose and there is no surprise that for something complex it will take a long time to reimplement it to whatever the new stan…

If the implementation really was sufficiently complete, then this is even worse! Why did they choose to vote something into the standard that is very complex and difficult to implement, but does not live up to the promises? Maybe they thought it would improve in the future, but isn't this a huge gamble?

I have heard rumors that certain people in the Visual Studio team have exaggerated the state of their modules implementation to speedrun the standardization process. I have no idea if that is really true, but it would explain a lot of things...

I'm not the only one who is asking these questions:

> I don’t know if they exaggerated their claims at the time, or if they didn’t properly fund the Visual Studio team since or what, but you can’t tell me 8 years wasn’t enough to make syntax highlighting work with modules. And if it is, then maybe there was something deeply wrong in their proposal and the committee should have asked to see the receipts before voting yes.

https://mropert.github.io/2026/04/13/modules_in_2026/

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

#119

Post by jcelerier »

maccard wrote: post #60
SuperV1234 wrote: post #49

Earlier quoted context omitted.

...so what? It's just a header you have to #include.

By that logic why would anything have to be standardised?

the only thing that should be standardized are things that cannot be done through libraries in an efficient way. Boost.PFR is great, I built a lot of things on it, but eventually you hit the limits of what a pure library approach can do -> language feature.

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

#120

Post by madduci »

spacechild1 wrote: post #68
delegate wrote: post #30

Earlier quoted context omitted.

I was very curious to see what C++ 26 brings to the table, since I haven't used C++ in a while. When I saw the 'no boilerplate' example, the very first thought that came to my mind: This is the ugliest, most cryptic and confusing piece of code I've ever seen. Calling this 'no boilerplate' is an insult to the word 'boilerplate'. Yeah, I can parse it for a minute or two and I mostly get it. But if given the choice, I'd…

> But if given the choice, I'd choose the C-macro implementation (which is 30+ years old) over this, every time. Why? The implementation is not pretty, but you only need to write it once and then it works for all enums. The actual usage is trivial, it's just a function call. The C macro version is horrendous in comparison. Why would I want to declare my enums like that just because I might want to print them?

Then why isn't part of the stdlib? Why should everybody maintain their own version?
Post reply on HN