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

Fun with C++26 reflection: Keyword Arguments

pydong.org

Post reply on HN
Print view View original

71–80 of 147 posts

Re: Fun with C++26 reflection: Keyword Arguments

#71

Post by gpderetta »

uecker wrote: post #58
Gibbon1 wrote: post #37

Earlier quoted context omitted.

Would be happy with a enum that's a named key value. key_enum one_two_three { FIRST = { .name = "first"}, SECOND = { .name = "second"}, THIRD = { .name = "third"}, LAST = { .value = 255, .name = "last"}, };

What is wrong with the following? Do you want type more type safety, e.g. linking the enumeration constants to the array? enum { FIRST, SECOND, THIRD }; struct { char *name; int value; } table[] = { [FIRST] = { .name = "FIRST", .value = 0 }, [SECOND] = { .name = "SECOND", .value = 1 }, [THIRD] = { .name = "THIRD", .value = 3 }, };

You still need generic code to link the enum type to its format string, for example for use in std::format or std::ostream.

Nothing really difficult, normally all of this is done by hand, which is tedious and error prone, or incorporated in a macro. It would just be nice if there was a standard provided turn-key solution to the problem.

Re: Fun with C++26 reflection: Keyword Arguments

#72

Post by gpderetta »

the_hoffa wrote: post #62
spacechild1 wrote: post #61

Earlier quoted context omitted.

> If C++ really wants to help "game-engines" or make actual strides, then it should add basic GUI support to the language itself. This feels like a total non-sequitur. What does GUI have to do with component and property systems? > why not add GUI!? Because that is 100% out of scope for the C++ standard library. Also, I don't even want to imagine what a GUI library designed by committee would look like...

Agree it's a non-sequitur; as is any idea of "game-engine" code in C++ (as the post I replied to mentioned), hence the argument. And 100% out of scope of C++, like the std::thread?? I've worked on many an embedded system that has no concept of threads, yet the C++ committee decided to add the std::thread as a part of the STL in C++11 instead of agree on a standard ABI. So why not GUI's, or sockets, or any other more…

Sockets has been in the work for the last 15 years. We almost got asio in the standard. There is significant interest in this, but also monumental bikeshedding.

A GUI proposal also was in the work for a while, then dropped because of lack of interest.

Threads definitely belong in the standard. Just because some platforms can't implement everything it doesn't mean the standard should be the minimum common denominator. Some embedded platforms don't even have malloc!

edit: but I think you are arguing in favor and I just failed at reading comprehension!

Re: Fun with C++26 reflection: Keyword Arguments

#73

Post by gpderetta »

RossBencina wrote: post #29
ranger_danger wrote: post #22

Earlier quoted context omitted.

yes a pointer to struct would be acceptable as well

In 1998 perhaps. It wouldn't be acceptable to today's C++ value-semantics crowd. Are you sure that you want to take the indirection penalty? or that the compiler will optimise it away?

If stack space usage is an issue, then it means that the struct is already being passed by hidden pointer (as opposed to using a register passing calling convention). Making the pointer explicit won't have any effect on performance (but it will on semantics).

Re: Fun with C++26 reflection: Keyword Arguments

#74

Post by badmintonbaseba »

drysine wrote: post #68
ratmeadow wrote: post #33

Earlier quoted context omitted.

> Why can't you just do this at the language level like any sane person? The reality is C++ is a ridiculously complex and legacy-ridden language, with a difficult goal to preserve backwards compatibility. I haven't read the history on the keyword args proposals but I'm guessing they were declined due to a deluge of silly edge case interactions with C++ semantics that became too hard to work around. Like how struct de…

>Like how struct designated initialisers have to be in order of member declaration due to object lifetime rules or something like that. It matters in which order sub-objects are initialized - if you have a class with the members A and B, and B takes pointer or reference to A in its constructor and does something with A, A better be already initialized. Sub-objects are initialized in the order of their declaration and…

You can't easily take the pointer to an other member in a designated initializer. It's still a problem for members that are implicitly initialized by their default member initializer, but that can be sorted out.

Re: Fun with C++26 reflection: Keyword Arguments

#75

Post by badmintonbaseba »

weinzierl wrote: post #44
SideQuark wrote: post #8

Earlier quoted context omitted.

Reflection is such an insanely useful tool that pretty much all modern languages have it. As usual C++ is 20 years behind language design and brings terrible syntax. But it is tremendously useful. https://en.wikipedia.org/wiki/List_of_reflective_programming...

The article is about compile-time reflection, which is not nearly as useful as what the Wikipedia article you linked is about. It's only upside is that it is "zero cost" by some definitions of cost. Runtime reflection on the other hand is useful but it also puts up obstacles not easy to overcome. For example it is one major reason we still have no decent ahead-of-time compilation in Java.

You can build runtime reflection on top of compile time reflection, it's impossible the other way around. Compile time reflection is a superset of what runtime reflection can do.

Re: Fun with C++26 reflection: Keyword Arguments

#77

Post by [deleted] »

flohofwoe wrote: post #48
weinzierl wrote: post #44

Earlier quoted context omitted.

The article is about compile-time reflection, which is not nearly as useful as what the Wikipedia article you linked is about. It's only upside is that it is "zero cost" by some definitions of cost. Runtime reflection on the other hand is useful but it also puts up obstacles not easy to overcome. For example it is one major reason we still have no decent ahead-of-time compilation in Java.

I'm in the opposite camp, runtime reflection is useless, and almost always points to a design flaw while compile time reflection is actually useful (for obvious things like automatically building a serialization layer or an UI which represents the type, or building types from other types). I'm sure that C++26 has implemented it in a way which is highly unpleasant to use though ;)

[deleted]

Re: Fun with C++26 reflection: Keyword Arguments

#78

Post by thom »

the_hoffa wrote: post #66
thom wrote: post #63

Earlier quoted context omitted.

People are going to build plugin and component systems whether we like it or not. People have massive investments in C++ whether we like it or not. These two concerns often intersect in game engines, apologies if that felt off topic.

Nah! I agree that plugin/component systems will be built out, no matter the language, more just trying to point out that C++, as-is-designed, in my opinion, seems like they're trying to go that route without actually going that route :| I'm more saying we should cut out the middle-man (as it were). The difference between C++03 and C++26 is, at a language/STL level, ultimately negligible when it comes to what I can "r…

Gotcha, totally fair points. It is an inherently conservative approach to standards, to take workarounds and pragmatic solutions that are already available within the community, and provide slightly cleaner (perhaps debatable) baked-in versions. You're right it doesn't add much, but at the same time... I feel the ick factor reducing with each release and my enjoyment of the language has grown over the years. I would certainly love to see those features used in common libraries and frameworks, but for practical reasons I suspect they think the same way you do, which is entirely valid.

Re: Fun with C++26 reflection: Keyword Arguments

#79

Post by [deleted] »

badmintonbaseba wrote: post #74
drysine wrote: post #68

Earlier quoted context omitted.

>Like how struct designated initialisers have to be in order of member declaration due to object lifetime rules or something like that. It matters in which order sub-objects are initialized - if you have a class with the members A and B, and B takes pointer or reference to A in its constructor and does something with A, A better be already initialized. Sub-objects are initialized in the order of their declaration and…

You can't easily take the pointer to an other member in a designated initializer. It's still a problem for members that are implicitly initialized by their default member initializer, but that can be sorted out.

[deleted]

Re: Fun with C++26 reflection: Keyword Arguments

#80

Post by pilianas »

drysine wrote: post #68
ratmeadow wrote: post #33

Earlier quoted context omitted.

> Why can't you just do this at the language level like any sane person? The reality is C++ is a ridiculously complex and legacy-ridden language, with a difficult goal to preserve backwards compatibility. I haven't read the history on the keyword args proposals but I'm guessing they were declined due to a deluge of silly edge case interactions with C++ semantics that became too hard to work around. Like how struct de…

>Like how struct designated initialisers have to be in order of member declaration due to object lifetime rules or something like that. It matters in which order sub-objects are initialized - if you have a class with the members A and B, and B takes pointer or reference to A in its constructor and does something with A, A better be already initialized. Sub-objects are initialized in the order of their declaration and…

You still don't need to syntactically require same order initialization, it's an easy job for a compiler to reorder things so that all dependencies work out - every language with order independent declarations have to do that for example.
Post reply on HN