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

151–160 of 214 posts

Re: Reflection for C++26

#151

Post by fluoridation »

meindnoch wrote: post #106
fluoridation wrote: post #38

Earlier quoted context omitted.

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

What are you talking about? At runtime, an enum value is just an integer. You need to look up the enum case that corresponds to your integer in order to convert it to a string. Which is precisely what the code above is doing.

Sure, but reflection requires some support from the compiler either way. There's no reason why if you have an expression like x.str, where the compiler can see that x is an enum, that it can't rewrite it into a table lookup like __Enum_strings[x]. This would work even if x is an unknown run-time value. This is basically what any other language that supports converting enums to strings natively does. I understand that the C++ committee prefers to delegate work to the standard library, but in this case it's stupid. Reflection needs support from the compiler. Just add new syntax and put it on the compiler, ffs!

Re: Reflection for C++26

#152

Post by tempodox »

Highly interesting, I'm looking forward to this.

But the `member_number` functions in § 3.2 look disturbing to me. It's not discernible how invalid arguments are handled. Normally I'd look at generated assembly to answer a question like that, but this probably doesn't make sense with compile-time-fu (`constexpr`)…

Re: Reflection for C++26

#154

Post by lallysingh »

maccard wrote: post #97
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

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 kee…

Also that the features c++ is getting are bolt on additions that we already have solutions for. I think fmt is a great example - fmt is a header only library that can be dropped in. Meanwhile std format was standardised without printing to stout. That took 3 years to standardise. Meanwhile we’re working on things like ranges, and instead of implementing them in the language it’s shoe horned in as a library feature -…

Ha! Modules. I wrote a basic version of that in 2006 for Boost. This is as big a useless mess as web components. It feels like c++ is in the legacy category with x86, still here, tolerable due to exponential efforts, and still dying for simpler solutions that aren't beholden to decades-old design mistakes. (variable instruction width, context-sensitive grammar, #include model, etc).

Re: Reflection for C++26

#155

Post by lallysingh »

chipdart wrote: post #110
physicsguy wrote: post #74

Earlier quoted context omitted.

> the people that really care found workarounds Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for.

> Or stopped writing C++, I'd consider myself one of these for many use cases I used to use it for. Some use cases like GUI programming sound like they are better addressed by specialized tech stacks. Nevertheless, either you're talking about greenfield projects or you are hard pressed to find a justification to rewrite a project in another framework. Claiming you stopped writing C++ doesn't fit the bulk of the exper…

Services get split up and some parts rewritten. The parts are often written in new languages.

Re: Reflection for C++26

#156

Post by lallysingh »

Grayskull wrote: post #86
CuriousCosmic wrote: post #41

Earlier quoted context omitted.

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 kee…

> They are coming quite fast and people regularly complain that new C++ has too many things for them to learn and keep up with. I never got this. Can't you just decide to use subset of the language? No-one forces people to use every single feature. It's okay to use C++ like "C with classes" and occasionally cool new thing, when it is right tool for the job. Only people where this argument is truly valid are compiler/…

For 1 person, sure. The larger the team, or the more teams involved, this drops from easy to completely impossible.

Re: Reflection for C++26

#157

Post by Maxatar »

fooker wrote: post #57
Maxatar wrote: post #34

Earlier quoted context omitted.

C++ has both return type polymorphism and inheritance. What it doesn't have is the kind of type inference that Haskell has. Its type inference is very limited.

You can't have two functions that differ in just the return type in C++

You certainly can and I know there are several JSON libraries that do it. The gist of it is to write a struct and overload the conversion operator for the set of return types you want to support, for example overload the conversion operator to int and std::string. As soon as the instance of that struct is used in a context that needs an std::string, then it calls the string overload.

Re: Reflection for C++26

#158

Post by throwway120385 »

germandiago wrote: post #53
throwway120385 wrote: post #23

Earlier quoted context omitted.

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.

I suggest you to take a look at Boost.Describe. I have a scripting layer in a game that needs to set properties in a C++ Model. I used a single Boost.Describe macro per struct and a generic get/set property. It worked very well and made me get rid of a lot of boilerplate. https://www.boost.org/doc/libs/develop/libs/describe/doc/htm...

Yeah, that looks like it would do what I need.

Re: Reflection for C++26

#159

Post by pjmlp »

coopierez wrote: post #123
pjmlp wrote: post #84

Earlier quoted context omitted.

It actually is, for anyone using Conan or vcpkg.

So our team switched to vcpkg recently and, while it has improved certain parts of our dependency process, it has also made other parts more complex. Notably when something suddenly goes wrong it is far more complex to figure out what actually happened (Though to be fair a lot of these issues also come from combining vcpkg with cmake). This led to most of my team revolting against vcpkg and now it looks like we might…

Until one needs to step out of a pure Go or pure Rust experience, and then it is a quite interesting build.rs file, Makefiles or shell scripts.

Re: Reflection for C++26

#160

Post by throwway120385 »

utensil4778 wrote: post #56
intelVISA wrote: post #47

Earlier quoted context omitted.

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

One could argue that template metaprogramming is a kludge DSL of its own.

It absolutely is. The root problem is that the language itself doesn't permit you to make statements about your constructs without learning an entirely different set of tools. Whereas other languages have these tools as a core component. Templates seem like they were added to resolve a bunch of problems with the macro system. You can see that in the earliest use of templates to eliminate a lot of boilerplate around containers that in C you might have used the preprocessor to do.

From there a lot of functionality for making statements about what something is has been bolted on to the side of what is really a very sophisticated type-aware preprocessor, and it shows. It's very painful to use it when you go from the core C++ language to the template, because the semantics are very different. Which the same can be said of C++->Preprocessor.

I think proper reflection should be a core part of the language that can be evaluated at compile-time with simple constructs. It's hard to articulate specifics but I think this proposal greatly simplifies working with type metadata to the degree that it's an approachable problem without using someone else's library. This proposal seems to do that in my opinion, and I think even some of the weaker programmers I've worked with could use this effectively.

Post reply on HN