Cost of enum-to-string: C++26 reflection vs. the old ways
vittorioromeo.com
Cost of enum-to-string: C++26 reflection vs. the old ways
1–10 of 189 posts
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#2Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#3[dead]
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#4I'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?
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#5Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
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.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#6No 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)
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#7Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
I was a fool to assume that the same forces shaping the ugliness of C++ syntax would not also be at work in C++ 26.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#8Oof, that first example (the idiomatic C++26 way) looks so foreign if you're mostly used to C++11.
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 iteration variable. It's a bit crazy but necessary for reflection to work usefully in the way the language sets it up.
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#9Earlier 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…
Zig's inline for is also evaluated at comptime:
Re: Cost of enum-to-string: C++26 reflection vs. the old ways
#10Another win for X macros and for C style in general, though the author didn’t declare it as such.