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

91–100 of 147 posts

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

#91

Post by witx »

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…

It feels to me that C++ has long become a language for "academic" or compiler-minded people to try yet another thing just for the sake of it or because its fun. Yes reflection eases some issues we have on C++ but the syntax is horrible and clutters the language

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

#92

Post by jjmarr »

NL807 wrote: post #28
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…

Honestly, all I ever want is to be enumerate a struct data member or an enum at compile time, and be able to get the name, type and value of each iterated member. That's it. That's all I want.

magic_enum addresses your issue but will absolutely kill compile time on a large project due to recursive template instantiation.

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

#93

Post by drysine »

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.

I think it is easy enough to be a potential footgun [0]:

  struct A { A(A*);};

  struct B {
    A a1;
    A a2;
  };

  void f()
  {
    B b{.a1 = A(nullptr), .a2 = A(&b.a1) };
  }
[0] https://godbolt.org/z/cGaxzh17T

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

#94

Post by hyperhello »

eqvinox wrote: post #41
hyperhello wrote: post #31

Earlier quoted context omitted.

At this point, you should just switch to JavaScript. The desperation to have the simple ease of JavaScript without having to say you're going near "that terrible language" is twisting C++ into ridiculous loops. I'm serious. It's like a bizarre Victorian relic now.

https://javascriptwtf.com/ Arguably this is worse than C++ because for basic things/beginner to intermediate users, the footguns in C++ are more benign (e.g. performance related, rather than correctness) than the ones in JavaScript.

The same tired edge cases. Especially the null pointers. Yes, but what did you want the language to do? Stop you? You can do that yourself.

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

#95

Post by lallysingh »

I'm disappointed to see the responses here. Reflection in C++ has been a wiggly sack of cats for decades. Of course it has to be all conpile-time. If you want to reify it, this is the way you get to choose the runtime version you like.

And, being conpile-time, it ain't gonna be pretty. The new operator is nice. They found something that'll work compatibly with existing code. This is not easy stuff.

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

#96

Post by kllrnohj »

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. That'd kill off 90% of the other framework/libraries out there.

Find me a single language that has an included GUI that anyone uses. I'll wait.

Even VB.NET, for which building GUIs was its entire reason to exist at all, has multiple GUIs officially, they couldn't even stick to one.

This is absolutely a terrible idea for a language, any language, to engage with at a language / standard library level.

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

#98

Post by pragma_x »

tjalfi wrote: post #11
anitil wrote: post #9

Earlier quoted context omitted.

I've seen cases where people do things like my_func(/*arg1=*/val1,/*arg2=*/val2) And I suppose you could write a validator to make sure that this worked. Or using an anonymous structure in C99, or a named structure in C89. And of course a pointer if you care about register/stack usage etc. I'm not sure what the other options are.

C++20 added designated initializers, so they're also an option. my_func({.arg1 = val1, .arg2 = val2});

Even though you need to declare a struct for this (or other) functions to receive these fields, I feel like this is the cleanest approach. What I'm not sure about is if reference, value, or pointer is the best way to let the compiler optimize this.

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

#99

Post by jcranmer »

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

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

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

#100

Post by bluGill »

Night_Thastus wrote: post #18
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…

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 (replacing loops)

I use templates, but only when I'm writing generic code. Templates in the right place can save a lot of code and errors. However they are rarely needed and so you only need a few people on a large project to write them, and everyone else can say "not in my subset of C++, talk to [someone else]"

> more advanced features you use, the easier it is to make subtle mistakes, confuse someone who hasn't seen that feature before,

Also the more people get used to seeing it. Soon everyone knows those things, and so they won't make the subtle mistakes of be confused. Of course you need to pick the right things to add. Ranges look really useful for people who work on a different type of problem from the type I normally work on - thus ranges are not in my subset of C++, but my impression is they should be very common in other areas. Modules are not currently on my list, but everything I know suggests in 5 years the tools will (finally!) work and I will be converting my code to modules. I'm not clear where reflection sits, I suspect like templates a few experts will be needed on a large project and everyone else just uses them - but only time will tell.

Post reply on HN