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

71–80 of 189 posts

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

#71

Post by spacechild1 »

SuperV1234 wrote: post #33
bluGill wrote: post #20

Earlier quoted context omitted.

I was thinking the same thing. Modules are still not widely used, it is a reasonable guess that there are a lot of optimization opportunities left.

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 it seems like a few powerful comittee members wanted to get modules into C++20 at any cost. This was just irresponsible.

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

#72

Post by psyclobe »

cv5005 wrote: post #57

Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever. I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program. Simple, effective, debuggable (…

Absolutely spot on, easier, and way more effective

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

#73

Post by [deleted] »

rddbs wrote: post #62
cv5005 wrote: post #57

Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever. I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program. Simple, effective, debuggable (…

One obvious answer is that people probably don’t want to write a whole parser and wire up new steps in their build pipeline just to do something simple like get the name of enum cases as a string. Without taking a stance on whether in-language meta programming facilities are good or bad, it’s not hard to find examples of cases where people find it useful to have them.

[deleted]

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

#74

Post by spacechild1 »

king_geedorah wrote: post #10

Another win for X macros and for C style in general, though the author didn’t declare it as such.

The downside is, of course, that it's ugly and very awkward to use.

That's the essence of C++: you're basically trading ergonomics for compile times.

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

#75

Post by wat10000 »

cv5005 wrote: post #57

Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever. I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program. Simple, effective, debuggable (…

Why would I write a parser that almost-but-not-quite matches the compiler's own parser, when I could just use the compiler's parser directly? I don't want to write a parser, and I especially don't want to debug weird corner cases where my implementation diverges somehow. I just want to write some code that goes like, for each field in T, do X.

C++ metaprogramming is bad, but the problem there is the C++ part, not the metaprogramming-in-the-language part.

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

#76

Post by mananaysiempre »

randusername wrote: post #7
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 a fool to assume that the same forces shaping the ugliness of C++ syntax would not also be at work in C++ 26.

Reflect/reify, quasiquote/unquote, etc. are the final boss of syntax design. Even Template Haskell looks rather bad.

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

#77

Post by [deleted] »

pandaman wrote: post #63
cv5005 wrote: post #57

Never quite understood why people are so obsessed with meta programming capabilities in a language, be it templates, comptime, macros, whatever. I program mostly in C, if I need 'meta' programming I just write another C program that processes C source code (I've written a simple C parser), then in my build script I build in two stages, build meta program, run it, build rest of program. Simple, effective, debuggable (…

Writing a C++ parser is much harder than a C parser to the point there had been just 3 parsers used among all C++ compilers for quite a while. So you'd need to use some library for parsing. So now you are looking into the library's parser compatibility with the compiler you are using (it might not support the C++ standard you are on at all, it can have bugs preventing it from parsing the code that the compiler parses…

[deleted]

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

#78

Post by kevin_thibedeau »

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?

Keep macro generated code isolated in self-contained wrapper functions that just return a static object corresponding to an argument. Then you can treat them like black boxes that never fail and never need to be stepped over.

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

#79

Post by mananaysiempre »

bluGill wrote: post #12
sagacity wrote: post #2

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

You realize c++11 is closer in age to C++98 than C++26?

I’m not sure the nominal publication date of a standard is all that relevant when the implementors’ reaction is as lukewarm as it has been to C++ ≥20.

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

#80

Post by samatman »

ginko wrote: post #9
CamouflagedKiwi wrote: post #8

Earlier quoted context omitted.

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: https://ziglang.org/documentation/master/#inline-for

Well yes, but the _effect_ is to unroll the loop for runtime, if the inline-for survives that long.

A for loop executed during comptime is just

    const stuff = comptime stuff: {
       for (0...8) |i| {
         // etc, build up some stuff
       }
       break :stuff some_stuff;
    };
The difference is that a comptime block won't leave behind runnable 'residue', only whatever data is constructed for later. An inline for might not leave behind an unrolled loop either, but it can.
Post reply on HN