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

131–140 of 147 posts

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

#131

Post by Tsche »

vouwfietsman wrote: post #65
harry8 wrote: post #45

Earlier quoted context omitted.

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

This is absolutely possible, even currently - albeit in a very much non-portable way. For example boost::pfr and my own (wip) repr library have the required machinery for this.

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

#133

Post by pjmlp »

kllrnohj wrote: post #122
pjmlp wrote: post #112

Earlier quoted context omitted.

It is the standard library on the platform, of course it counts. Get Smalltalk-80 reference manual without the UI documentation of its standard library, and no, GNU Smalltalk is not a complete implementation.

We're not talking about platforms, we're talking about languages.

Which in several cases are the same.

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

#134

Post by DannyBee »

bluGill wrote: post #104
DannyBee wrote: post #88

Earlier quoted context omitted.

The fascination i sort of get - sometimes rabbit holes are fun to jump down if you have time. I'm working on a satisfactory node modeling tool for fun, and built one of the stores (I have a few different stores) using CRDT's and added collaborative support over webrtc. Is it practical? The result, yes. The process - no, it's a total waste of time and energy compared to much simpler alternatives. No question. Is it fu…

> C++ exposes all this complexity because it's not willing to break anything, ever. That is also why people use C++ for large complex problems. Not doing that is why python3 took forever to replace python2. When you have a lot of code that works it isn't worth the money to rewrite it if you can help it.

Python2-3 is a worst case example where the benefits were small or negative compared to cost.

There are also plenty of very successful languages used for large complex problems and have broken compatibility in various ways over the years.

You are right nobody wants to pay to rewrite it but if the tooling takes care of it for you nobody cares about it.

Python 2-3 had tooling that, for larger customers and projects, often could not do even 50% of the conversion, and when it came out the other side, nobody felt it was really better.

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

#135

Post by pjmlp »

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…

Easy, anything Khronos related.

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

#136

Post by xmcqdpt2 »

likpok wrote: post #118
pilianas wrote: post #80

Earlier quoted context omitted.

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.

You don't need to require same-order initialization, but allowing people to do different orders will be confusing when actions are reordered behind the scenes. Especially imagine if there are dependencies between the objects you're passing in. struct A { B one; C two; }; struct B { B() { cout Mixing up the order is confusing: A{.two=B(),.one=A()} since `two` is initialized after `one` despite coming before (the comma…

Scala does it by pulling out the keyword arguments to variables so that your example would become

{ val x$1 = B() val x$2 = A() A(.one = x$2, .two = x$1) }

This maintains left-to-right evaluation order while allowing you to pass arguments in any order.

There is probably some dark and forbidden reason why C++ can't do that.

ETA: That's basically what the post does.

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

#137

Post by xmcqdpt2 »

jcranmer wrote: post #99
flohofwoe wrote: post #48

Earlier quoted context omitted.

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 ;)

The element of runtime reflection that is the most useful is something along the lines of "here's function, here's a list of arguments, go call this function with those arguments".

Having to do this by reflection is a problem in principle solvable by types. Here is a function of type (A, B, C) => R, and here is a tuple of arguments of type (A, B, C), go call this function with those arguments.

Most programming languages make it hard to easily express those constraints so reflection is used instead.

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

#138

Post by Night_Thastus »

bluGill wrote: post #100
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 have almost entirely removed loops from my definition of the simple subset of C++. Turns out that in nearly every case anytime I think loop I'm able to find a STL algorithm that does the same thing in a more expressive way. I do use lambdas all the time, they are very powerful and so worth learning the complex syntax to make them work. I strongly recommended you add them to your list of things you use all the time…

>Also the more people get used to seeing it.

This is a great idea in theory, but doesn't always hold up well. With a sufficiently large and old project, and when people move on and off either parts of the code or the entire project regularly...it doesn't hold up as well.

No one may see or touch that code again for years. By the time someone realizes there's a missed edge case or it needs expansion, it may simply be too late. The person that worked on it may be gone completely or haven't worked on that part of the code in those years.

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

#139

Post by igouy »

pjmlp wrote: post #117
igouy wrote: post #114

Earlier quoted context omitted.

"The standard does not attempt to specify areas where current implementations differ in significant ways. In particular, as the goal statement implies, we did not include graphics, user interface , or database accessing objects in the library." 1997 DRAFT ANSI Smalltalk Standard https://wiki.squeak.org/squeak/uploads/172/standard_v1_9-ind...

That is not Smalltalk-80 as originally designed....

Smalltalk-80 is not Smalltalk "as originally designed".

(Moving goal posts.)

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

#140

Post by verandaguy »

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…

I think there's a humour to C++ being like Python in that, left alone, the language's community will almost immediately try and stuff as much syntax as possible into the language.

The difference is how much power the community has to turn these syntactic fever dreams a reality. With C++, you get first-class stuff like the STL and even the C preprocessor, and now reflection. With Python, it usually comes down to magic method abuse (see pathlib's use of `__div__`), maybe messing around with metaclasses, and the PEP process (though I think they're pumping the brakes at this point -- walrus was fun, but I really hope PEP 750 doesn't make it in, and it seems to me that it'll stall).

You technically have `ast`, but that'll only go so far since unless you really go overboard with your hack, you still have to write valid, parseable Python before `ast` will ingest it.

Post reply on HN