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

21–30 of 189 posts

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

#21

Post by cogman10 »

bluGill wrote: post #11
HarHarVeryFunny wrote: post #6

No doubt reflection has been built with other use cases in mind, but it sure would have been nice just to have std::to_string(enum)

C++ conference speakers (including keynotes) are now begging everyone to stop using enum to string in their example. While they are a simple and easy to understand example, reflection is for much more interesting problems. I can't think of any other example that I would type into a comment box or put on a slide.

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. (IDK if C++'s reflection is as capable, but this is what was enabled by java's reflection).

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

#22

Post by bluGill »

w4rh4wk5 wrote: post #17
randusername wrote: post #13

I can't imagine myself using reflection much, but maybe it will eliminate a lot of feature proposals bogging down the committee and they can focus on harder problems. It would be cool if the stated goal of C++29 was compile times.

I'd argue reflection is very much a feature for libraries. You wouldn't use it directly, but your JSON / YAML serialize is then built on top of it. So are your bindings for scripting engines like Lua.

There are a lot of things that are very very important for a tiny niche. In any non-trivial project you will end up with a lot of custom libraries and some of them really benefit from some obscure feature that no place else in your project would want.

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

#23

Post by maccard »

bluGill wrote: post #11
HarHarVeryFunny wrote: post #6

No doubt reflection has been built with other use cases in mind, but it sure would have been nice just to have std::to_string(enum)

C++ conference speakers (including keynotes) are now begging everyone to stop using enum to string in their example. While they are a simple and easy to understand example, reflection is for much more interesting problems. I can't think of any other example that I would type into a comment box or put on a slide.

Serialization is the canonical example. Being able to turn

    struct MyStruct {
      int val = 42;
      string name = "my name";
    };
into

    {
      "val": 42, // if JSON had integers, and comments of course
      "name": "my name",
    }
is incredibly powerfuly. If reflection supported attributes (i can't believe it shipped without, honestly), then you could also mark members as [[ignore]] and skip them.

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

#24

Post by david422 »

cogman10 wrote: post #21
bluGill wrote: post #11

Earlier quoted context omitted.

C++ conference speakers (including keynotes) are now begging everyone to stop using enum to string in their example. While they are a simple and easy to understand example, reflection is for much more interesting problems. I can't think of any other example that I would type into a comment box or put on a slide.

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

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

I find this to be very powerful, and also very unintuitive/undiscoverable at the same time.

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

#25

Post by agentultra »

w4rh4wk5 wrote: post #17
randusername wrote: post #13

I can't imagine myself using reflection much, but maybe it will eliminate a lot of feature proposals bogging down the committee and they can focus on harder problems. It would be cool if the stated goal of C++29 was compile times.

I'd argue reflection is very much a feature for libraries. You wouldn't use it directly, but your JSON / YAML serialize is then built on top of it. So are your bindings for scripting engines like Lua.

Also nice for UI tooling; game tools, debuggers, etc. Pull apart a struct and display it on screen and not have to patch the UI tool every time you change the struct is pretty nice.

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

#26

Post by usefulcat »

cenamus wrote: post #15
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?

I mean it's still C++ that's compiled and executed, surely the compiler would be able to provide a way to hook into that?

I don't recall the source, but I don't believe most (any?) c++ compilers implement compile-time code evaluation by compiling and running code.

For one thing they are required to disallow all undefined behavior for compile time execution, and some forms of UB only occur when the code is run.

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

#27

Post by bluGill »

maccard wrote: post #23
bluGill wrote: post #11

Earlier quoted context omitted.

C++ conference speakers (including keynotes) are now begging everyone to stop using enum to string in their example. While they are a simple and easy to understand example, reflection is for much more interesting problems. I can't think of any other example that I would type into a comment box or put on a slide.

Serialization is the canonical example. Being able to turn struct MyStruct { int val = 42; string name = "my name"; }; into { "val": 42, // if JSON had integers, and comments of course "name": "my name", } is incredibly powerfuly. If reflection supported attributes (i can't believe it shipped without, honestly), then you could also mark members as [[ignore]] and skip them.

It is powerful, but I'm not sure it is a good idea. Other languages have it, and there is lots of experience in all the ways things go wrong in the real world. I'm inclined to say you should hand write this code because eventually you will discover something weird anyway.

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

#28

Post by NooneAtAll3 »

CamouflagedKiwi wrote: post #8
ginko wrote: post #5

Earlier quoted context omitted.

Is it? I'm mostly used to (pre-)C++11 and the only unusual operators I see are ^^T (which I presume accesses the metadata info of T) and [:e:] (which I assume somehow casts the enumerator metadata 'e' to a constant value of T). And template for but I assume that's like inline for like in zig.

requires is also new (not sure exactly when that appeared, it's after the last time I wrote C++ in anger) although I think it's fairly clear what it means. I can only guess at the other two. Not familiar with Zig but AFAICT `inline for` is about instructing the compiler to unroll the loop, whereas `template for` means it can be evaluated at compile time and each loop iteration can have a different type for the iterat…

requires is concept, one of big-C-words of ++20

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

#30

Post by delegate »

sagacity wrote: post #2

Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.

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 choose the C-macro implementation (which is 30+ years old) over this, every time. Or the good old switch case where I understand what's going on.

I understand that reflection is a powerful capability for C++, but the template-meta-cryptic-insanity is just too much to invite me back to this version of the language.

Post reply on HN