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

51–60 of 189 posts

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

#51

Post by bluGill »

SuperV1234 wrote: post #40
bluGill wrote: post #27

Earlier quoted context omitted.

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.

I think this is a very bad take -- once you write it by hand you have to manually keep it in sync with the actual struct and ensure you made no mistakes. Reflection guarantees 1-1 future-proof mapping with the actual C++ struct, avoids boilerplate, and ensures that the serialization logic is correct.

The protocol is important though, not the internal structure. When you only have exactly one version of a program talking to the same version of itself you don't care. However when you are mixing versions or worse programming language (and thus can't mix structs which are implementation details of your language) the protocol is what matters.

That is if you are worried about doing this by hand reflection is not the answer, something like protobuf where your data structures are generated is the answer.

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

#52

Post by shooly »

SuperV1234 wrote: post #50
delegate wrote: post #46

Earlier quoted context omitted.

Have you ever used other (modern) programming languages ? In a lot of languages, you achieve the same with 1 line of code. It's not about familiarity, it's about the fact that it's a long and convoluted incantation to get the name of an enum. Why do I have to be familiar with all those weird symbols just to do a trivial thing ? Update: Zig: const Color = enum { red, green, blue }; const name = @tagName(Color.red); //…

C++: enum Color { red, green, blue }; auto name = to_enum_string(Color::Red); // "Red"

... and where does that `to_enum_string` come from exactly? It doesn't seem to be built-in, which is the point of the parent comment.

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

#53

Post by varispeed »

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.

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

#54

Post by miguel_martin »

I agree with some other's in this thread: this is example is not great, but I get why it was used: to compare with X-macros. How about something that would require code-generation e.g. via libclang?

For example, what does https://miguelmartin.com/blog/nim2-review#implementing-a-sim... look like with C++26's std::meta::info?

My guess is: libclang is more suited for this situation if you care about compile times, even if Python is used.

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

#55

Post by psyclobe »

Man that aucks was looking forward to some kind of speed improvement. Using magic enum atm and I guess we'll continue to do so.

C++ build times are hard pill to swallow when migrating from c. This is just another reason we'll probably stick to writing c as t the company where I work. It's like asking someone to give up instant compilation for cleaner easier to read apps?

Also now that we have cleanup handlers in c (destructors) even less of a reason to move...

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

#56

Post by SuperV1234 »

shooly wrote: post #52
SuperV1234 wrote: post #50

Earlier quoted context omitted.

C++: enum Color { red, green, blue }; auto name = to_enum_string(Color::Red); // "Red"

... and where does that `to_enum_string` come from exactly? It doesn't seem to be built-in, which is the point of the parent comment.

It's a fair comparison. The parent comment isn't showing the compiler source code for the built-in reflection mechanisms.

You won't have to care about ^^ and [:X:] if you just want to consume reflection-based utils, which was the whole point of my comment.

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

#57

Post by cv5005 »

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 (the meta program is just normal C), infinite capabilities - can nest this to arbitritary depths, need meta-meta programming? Make a program that generates a meta program.

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

#58

Post by theICEBeardk »

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?

The answer is being debated at the moment in c++ papers and building on experience from other languages with extensive compile time evaluators like D. One thing that is happening is that we will get compile time exceptions (a paper for that is aiming to add this to the language in c++29 has come out) which may help us in reporting problems. Which will be important as there is also a lot of papers and talk about an extension of reflection allowing for better output generation which as far as I know was deferred until reflection had been accepted.

But there is also good news that with the advent of JIT like components for compile time evaluation in progress and the like of CLion having the beginnings of a compile debugger in combination with concepts there is a chance some help is available and on the way.

However right now you have to rely on compiler errors and static_asserts which is not ideal of course.

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

#59

Post by ironman1478 »

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

Meta programming in C++ can enable you to remove lots of runtime branching in your code at the cost binary size.

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

#60

Post by maccard »

SuperV1234 wrote: post #49
maccard wrote: post #47

Earlier quoted context omitted.

Sure, but > The magic sauce? Boost.PFR! An incredibly clever library that enables reflections on aggregates, even in C++17. That's not vanilla C++!

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

By that logic why would anything have to be standardised?
Post reply on HN