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

131–140 of 189 posts

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

#131

Post by pjmlp »

SuperV1234 wrote: post #42
cogman10 wrote: post #21

Earlier quoted context omitted.

It comes up pretty frequently in java. Serialization/Deserialization, adding capabilities based on type, Adding new capabilities to a type, general tuning (for example, adding a timing or logging call onto methods). Almost all the Java web frameworks are giant balls of reflection. Name a function the right way or add the right magic annotation and the framework will autowire it correctly. It's a pretty powerful tool.…

Java reflection is another beast altogether as it is runtime reflection. C++26 reflection is purely compile-time , which not only means it adds zero runtime cost, but also prevents those kind-of-insane use cases you see in Java and C#.

I think C++ devs have to eventually update their knowledge how Java and .NET work when talking about reflection.

Yes, originally they only supported runtime reflection.

Nowadays they have compile time tooling as well, via plugins, annotation processors, and code generators.

Which is exactly how you can have a Spring like frameworks that do all the AOP magic at compile time, for native code with GraalVM or OpenJ9, like Quarkus or Micronaut.

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

#132

Post by uecker »

spacechild1 wrote: post #86
uecker wrote: post #81

Earlier quoted context omitted.

Are X macros awkward? I find them very straightforward and clear.

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...

In practice it is written like like this:

  #define MY_ENUM(x) x(MY_A) x(MY_B) x(MY_C)
  enum my_enum { MY_ENUM(ENUM_ENTRIES) };

  static const char *my_enum_names[] = { MY_ENUM(ENUM_NAMES) };
but one could also make it even more compact if one cared.

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

#133

Post by gpderetta »

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 compiler doesn't need to open the same file multiple times. It can remember if a a file is guarded or not every time it sees its name.

My understanding is that this is an optimization that has been available for a very long time now.

The only issue is if a file is referred through multiple names (because of hard links, symlinks, mounts). That might cause the file to be opened again, and can actually break pragma once.

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

#134

Post by wiseowise »

SuperV1234 wrote: post #43
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…

It is "cryptic" and "ugly" to you just because you're not familiar with it. You'd pick the macro-based implementation because you are familiar with it. Seeing this argumentation is so tiresome, because it feels like there is a lack of self-awareness regarding what is "familiar" and what isn't, which is subconsciously translated to "ugly" and "bad".

No, it is objectively cryptic and ugly. I honestly don’t understand how can anyone keep up with this garbage, but the ship has sailed long time ago. It is just a soup of symbols at this point.

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

#135

Post by wiseowise »

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?

Typical C++ dev schizophrenia. In one thread complain about Node and its death-by-a-thousand-packages, then suggest the same in another.

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

#136

Post by w4rh4wk5 »

varispeed wrote: post #53
w4rh4wk5 wrote: post #4

I've been wondering about debug-ability of code using reflection. X-Macros are quite annoying to step through in most debuggers, though possible. While the code in the first example is evaluated fully at compile-time, how would you approach debugging it?

Why people are still using debuggers? I never felt the need for them when doing TDD.

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

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

#137

Post by gpderetta »

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…

Agree that proof of implementation and real world experience should be a requirement for standardization. But it is a catch-22: implement it's are probably not always too keen to spend time on a large feature if it is not clear that it will be standardized.

In practice both clang and VS have had some form of module support for quite a while, but the final standard ended up being different from either implementation (shaped by their experience, and certainly with inevitable last minute inventions).

I wonder if for some features the committee should vote for general guidelines, the delegate a third party (one or more implementors) to come up with both an implementation and standardese with the understanding that it will be fast-tracked in wit too much bike-shedding

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

#138

Post by pjmlp »

wiseowise wrote: post #135
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?

Typical C++ dev schizophrenia. In one thread complain about Node and its death-by-a-thousand-packages, then suggest the same in another.

Don't put assumptions in others heads.

First of all, the only correct way to use package managers is with validated internal repos, don't vibe install, that goes for node, and goes for C++ as well.

Second this thread was all about how code lands in one's computer.

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

#139

Post by SuperV1234 »

shooly wrote: post #109
SuperV1234 wrote: post #105

Earlier quoted context omitted.

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?".

  #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.

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

#140

Post by varispeed »

w4rh4wk5 wrote: post #136
varispeed wrote: post #53

Earlier quoted context omitted.

Why people are still using debuggers? I never felt the need for them when doing TDD.

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.
Post reply on HN