Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Reflection for C++26

isocpp.org

Post reply on HN
Print view View original

41–50 of 214 posts

Re: Reflection for C++26

#41

Post by CuriousCosmic »

stiglitz wrote: post #28
lallysingh wrote: post #22

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it. Looking at the examples ( https://isocpp.org/files/papers/P2996R4.html#examples ) what really stands out is the…

By ”stagnation” do you mean “not getting new features”?

C++ has gotten a ton of quality of life features with each update. The issue is less that new features aren't coming and more that new features bake through countless iterations of proposals for close to or often over a decade until everyone in WG21 is happy.

So it's not that we aren't getting features. They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. The issue is that those are the same features everyone has been asking for for over a decade so the people that really care found workarounds and eventually move over to the new std way of doing things when they can while everyone else continues waiting for that one feature they really care about.

Re: Reflection for C++26

#42

Post by rerdavies »

vlovich123 wrote: post #40
stiglitz wrote: post #28

Earlier quoted context omitted.

By ”stagnation” do you mean “not getting new features”?

N3340 is from 2011. Prior to c++11 they had failed to deliver major changes to the language. And arguably the disfunction is still there where big ideas get destroyed in committee (reflection) or take forever and come out half-baked (modules).

Speaking of half-baked, did continuations get fixed?

Re: Reflection for C++26

#43

Post by CuriousCosmic »

kstrauser wrote: post #33

I haven't touched C++ since undergrad. Neither have I written any Qt code. But from memory, doesn't Qt's moc implement some of this stuff because it wasn't available in C++? Could this replace moc?

Qt's moc can already be replaced and it increasingly is being relied on less and less as time goes on but dropping moc requires dropping all lower C++ standards or maintaining separate moc and modern-c++ versions.

And while it can currently be replaced with templates alone in fairly old versions of C++ (C++14 is the oldest I think), compile times are egregious unless you use very new, shiny features.

And as much as I am pro "move to new shiny C++", one of the big commercial uses of Qt is in semi-embedded applications like car entertainment centers where you are stuck with whatever (often outdated) toolchain your SOC source relies on. So pushing for shiny new Qt risks either splitting Qt in half or abandoning a lot of very well paying users.

Re: Reflection for C++26

#44

Post by [deleted] »

stefanos82 wrote: post #14

Can I ask a naive question that consists of two parts and please don't flame me? lol * What type of problems static reflection could solve, in general? * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

[deleted]

Re: Reflection for C++26

#45

Post by rerdavies »

thechao wrote: post #19
Dwedit wrote: post #3

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the re…

extern templates address the issue of having multiple instances of a template being expanded inline, with only minimal mess and fuss. (A way to prevent inlining of templated code would have been nice too).

Re: Reflection for C++26

#47

Post by intelVISA »

throwway120385 wrote: post #23
quotemstr wrote: post #17

Earlier quoted context omitted.

> What type of problems static reflection could solve, in general? Imagine making a plain struct Point { float x; float y; }; and wanting to serialize it to JSON without further ceremony

This is the thing that's driving me away from C++ very quickly. A big part of our code base is code that handles this, and it either has to be in a DSL and constantly recompiled or we have to make a bunch of boilerplate. It's a huge problem for the language not to be able to do this.

Serialization is largely a Solved Problem in modern C++ thanks to template metaprogramming. Wrangling a kludge DSL instead of Serialize betrays poor lang knowledge...

Re: Reflection for C++26

#48

Post by zarzavat »

thechao wrote: post #19
Dwedit wrote: post #3

Compile time or runtime? Compile time reflection would be completely painless and bloat-free.

Having implemented reflection in languages like C(++), before, it is most certainly not bloat-free. There are sorts of 'obvious' things programmers do (like enum-reflection) that end up injecting strings all over the place. The overhead is (worst case) proportional to the source-code size, in those cases. In other cases, you end up with bloat proportional to heavily-utilized template libraries. However, unless the re…

I always thought it’s good practice in C/C++ to have only one translation unit in release builds e.g. SQLite amalgamations, instead of relying on LTO. It also speeds up compilation because it isn’t recompiling the same header files over and over again.

Re: Reflection for C++26

#49

Post by kllrnohj »

fluoridation wrote: post #38
greenavocado wrote: post #29

Earlier quoted context omitted.

Converting enum values to strings, and vice versa enum class Color { Red, Green, Blue }; template std::string enum_to_string(E value) { constexpr auto enum_info = reflect(E); for (const auto& enumerator : enum_info.enumerators()) { if (enumerator.value() == value) { return std::string(enumerator.name()); } } return "Unknown"; } template E string_to_enum(const std::string& str) { constexpr auto enum_info = reflect(E);…

This is terrible. You can't just do Enum::Member.str or something?

That'll inevitably be a utility function that exists, but C++ generally prefers broadly useful language primitives over single-case helpers

Re: Reflection for C++26

#50

Post by mehrdadn »

jjmarr wrote: post #11
TillE wrote: post #7

Finally. I think there have been proposals since C++17 at least, and all I really wanted is for them to solve the common problem of basic static reflection for enums (without hacks like magic_enum uses).

magic_enum is killing my build time with endless template instantiations. Is this going to be faster?

Do you think you could try my library [1] and let me know how it performs in comparison? I've been curious about its compile-time performance, but I've never tried to compare its performance against that of magic_enum.

[1] https://news.ycombinator.com/item?id=32236447

Post reply on HN