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

61–70 of 147 posts

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

#61

Post by spacechild1 »

the_hoffa wrote: post #59
thom wrote: post #52

C++ reflection is now good enough that hopefully we’ll start to see more game engines using it to work out components and properties instead of weird macros. jcelerier’s work on things like Avendish really does feel quite fresh and modern, which is not my usual reaction to C++ frameworks. Obviously it’s lagging a good 20 years behind C# et al but we’ve come a long way since IUnknown.

I'm not sure if you mean to have a /s in there, but personally I never really liked reflection. C# had it but it was also in part because it interop'd with .NET which had C++.NET, VB.NET, F#.NET, VBScript.NET, ASP.NET, Core.NET, Web.NET, Net.NET and so much more .. reflection was an "easy" way to have other dev's interact with each others code as a type of "contract". I really like C# and what it can do, but having t…

> 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...

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

#62

Post by the_hoffa »

spacechild1 wrote: post #61
the_hoffa wrote: post #59

Earlier quoted context omitted.

I'm not sure if you mean to have a /s in there, but personally I never really liked reflection. C# had it but it was also in part because it interop'd with .NET which had C++.NET, VB.NET, F#.NET, VBScript.NET, ASP.NET, Core.NET, Web.NET, Net.NET and so much more .. reflection was an "easy" way to have other dev's interact with each others code as a type of "contract". I really like C# and what it can do, but having t…

> 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 "common" modern idiom?

If you don't want to imagine what a GUI library designed by committee would look like, I'd argue what a language like C++ looks like designed by committee (6 versions in 10 years).

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

#63

Post by thom »

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…

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.

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

#64

Post by gpderetta »

If you are willing to use macros anyway, you can make the following work in C++ today:

   foo($(bar)=10, $(baz)="hello");
In fact you could 10 years ago when I implemented it[1]; in fact it allows significantly more than just named arguments (named tuples!), but please, consider it as some sort of art and not really something that should be anywhere close to production.

[1] https://github.com/gpderetta/libtask/blob/a5e6e16ddc4e00d9f7...

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

#65

Post by vouwfietsman »

harry8 wrote: post #45
arjonagelhout wrote: post #24

Earlier quoted context omitted.

When I started out programming in C#, I used reflection sometimes to circumvent the language’s design and restrictions. This resulted in brittle and hard to reason about code. Reflection should never be used to do this. So I do think you’re right that reflection can (and will) be abused by beginners if present as a language feature. With that said, I don’t know much about the internals of the C++ compiler, but having…

>I think the important thing is just being able to serialize and deserialize POD structs to and from some representation (e.g. json). For more advanced data, such as images or specific binary (file) formats, it’s easier to write custom writing / reading, encoding / decoding logic. Why not just use a visitor? (Genuine question, not c++ snark).

Takes a bunch of manual work per POD, that's the gist of it.

Fundamentally, if I have struct { int x = 3; std::string y = "bla"; }

I want the json to look like { x: 3, y: "bla" } without writing any code specific to the struct, and have it work bidirectionally. This is currently not possible because of a lot of reasons, but most trivially because the names "x" and "y" do not even exist anymore in your compiled code.

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

#66

Post by the_hoffa »

thom wrote: post #63
the_hoffa wrote: post #62

Earlier quoted context omitted.

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…

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 "really do" with the language if I started in 03 .. and I don't mean that 26 doesn't "add more", but if I started with 03 and didn't have threading, file handling, delegates (std::function), sockets, graphics, and so much more, I'd likely use something that wrapped all of that (a plugin/component system) ... and switching away from that with an "antiquated" code base would be really hard at this point. Using 03 with a library and then just making it compile with C++26 doesn't really "add much", and switching away from that component system to C++26 requires design, building, testing, etc. etc. :|

And even if I'm starting with C++26 now (assuming my compilers are actually compliant, stable, non-breaking, ABI resilient and/or are actually available across the various platforms I want to target), while it does give me a lot more of a feature-set, how much of that is actually viable from an efficiency (CPU/memory) perspective over just proper/decent C++03/11 (I say 11 because of the threads) ...??

I know it's also up to the individual programmer using C++ to actually "do it good", so it's more just an old-man-yelling-at-clouds rant (observation) at how C++ is evolving, lol!

To be clear: not trying to be argumentative, I regularly work in C++ and enjoy it over many other languages .. just "saying" is all, hehe :)

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

#68

Post by drysine »

ratmeadow wrote: post #33
anon-3988 wrote: post #5

I just don't understand why some people are so fascinated by this. Can you all admit that this is not at all practical? I swear C++ folks like it for the sake of it. No other engineer do this. Only antiques people or whatever. Can you imagine an engineer that is adamant on using his mystifying bespoke tool instead of just using a ruler. "But what if I have to measure it in the 4th dimension!?". I was expecting someth…

> 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 having different order of designed initializers would be confusing. In fact, exactly that problem we have in C++ with the list of initializers of base classes and data members in constructors.

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

#69

Post by drysine »

arjonagelhout wrote: post #23
Night_Thastus wrote: post #18

Earlier quoted context omitted.

Personally, I write the simplest subset of C++ I possibly can at all times. Loops, variables, classes and the STL library when useful. The more advanced features you use, the easier it is to make subtle mistakes, confuse someone who hasn't seen that feature before, or just make everyone working on the software wary of ever touching it.

I do the same thing. C++’s feature is incredibly broad, and sprinkling in just a bit too much templating can result in code that is cleaner, but harder to reason about when reading it back after a month. For example, using C++ 20 ranges over simple loops is an example of where brevity and “cleanliness” can reduce clarity because the heavy templating and operator overloading hides what the code actually does. On the o…

>hides what the code actually does.

As does any function call.

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

#70

Post by kzrdude »

anon-3988 wrote: post #5

I just don't understand why some people are so fascinated by this. Can you all admit that this is not at all practical? I swear C++ folks like it for the sake of it. No other engineer do this. Only antiques people or whatever. Can you imagine an engineer that is adamant on using his mystifying bespoke tool instead of just using a ruler. "But what if I have to measure it in the 4th dimension!?". I was expecting someth…

Exploring like this is a way to get familiar with the feature, explore its limits and inform you on how to use it in the future.

It's curiosity, play and learning. It's great.

Post reply on HN