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

171–180 of 214 posts

Re: Reflection for C++26

#171

Post by meindnoch »

maccard wrote: post #162
meindnoch wrote: post #105

Earlier quoted context omitted.

>instead of implementing them in the language it’s shoe horned in as a library feature Quite the opposite. Proliferating the language itself with ad-hoc constructs would be shoe-horning.

I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated eq…

>Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself.

False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

Re: Reflection for C++26

#172

Post by bluGill »

CuriousCosmic wrote: post #168
bluGill wrote: post #141

Earlier quoted context omitted.

> Can't you just decide to use subset of the language? That is harder than it sounds. First you have to select which subset to use, it is almost impossible to get any two engineers to agree on that - if you do get agreement that is a bad sign - generally it means the people in the room don't know C++ well enough to make the decision and so you choose the wrong one. The best you can hope for is a compromise where nobo…

You can still enforce a style guide and limit certain constructs via code review. Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review. The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of supp…

> during code review.

There is the problem - code reviews are done by humans and so it is really easy to read some code and not think "wait this is new code it can't do that anymore". I read a lot of old code as part of my job and it often isn't worth the bother to update working code to new standards.

> it's a lot harder to justify avoiding new features than it is to justify avoiding old features

The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.

Re: Reflection for C++26

#173

Post by maccard »

meindnoch wrote: post #171
maccard wrote: post #162

Earlier quoted context omitted.

I disagree completely. Libraries like ranges are dumped into algorithm, and are de-facto considered parts of the language. Reflection has gone back to have range support added, for example. Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated eq…

>Another one is that span has a performance overhead due to it being implemented as a normal type. If it was part of the language rather than a library type, the compiler could make assumptions about it, but instead it’s treated equivalent to me writing it myself. False. Nothing prevents compilers from giving their own stdlib types special treatment under the hood.

That would be an ABI break which is just not happening, and you know it. As it is we’ve decided it’s more important to be able to use std span from libc++ on clang than it is to have an optimised version for people on their tool chain.

Re: Reflection for C++26

#174

Post by CuriousCosmic »

bluGill wrote: post #172
CuriousCosmic wrote: post #168

Earlier quoted context omitted.

You can still enforce a style guide and limit certain constructs via code review. Plenty of the modern C++ people already do this by enforcing things like "no raw loops", "no raw pointers", or "no raw synchronization primitives" during code review. The issue is that it's a lot harder to justify avoiding new features than it is to justify avoiding old features unless you have a tooling specific reason (ex lack of supp…

> during code review. There is the problem - code reviews are done by humans and so it is really easy to read some code and not think "wait this is new code it can't do that anymore". I read a lot of old code as part of my job and it often isn't worth the bother to update working code to new standards. > it's a lot harder to justify avoiding new features than it is to justify avoiding old features The problem is the…

> The problem is the opposite - people keep using old features when the new is better. I realize not everything new is better, but most of them are, yet people keep refusing to learn and use the new thing without good justification.

I think we are saying the same thing here. Often the new is better so it's hard to really justify sticking to the old outside of project specific reasons (i.e. toolchain doesn't support new std). That people do it has less to do with justification and more to do with time commitment or laziness and the excuses given tend to fall away once pressed.

Re: Reflection for C++26

#175

Post by fluoridation »

meindnoch wrote: post #163
fluoridation wrote: post #151

Earlier quoted context omitted.

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…

So your gripe is that you have to write `enum_to_string(x)` instead of `x.str()`? And this is of such importance, that this needs to be included in the C++ language itself, as a special case of the dot operator. Correct? >Reflection needs support from the compiler. Just add new syntax and put it on the compiler, ffs! Converting enums to strings is one use case for reflection. Do you suggest introducing bespoke syntax…

>So your gripe is that you have to write `enum_to_string(x)` instead of `x.str()`? And this is of such importance, that this needs to be included in the C++ language itself, as a special case of the dot operator. Correct?

My gripe, if you will, is that converting an enum value to a string is a basic feature (as in, not reducible to other features) of every language that supports doing that. Not everything should be part compiler part library. And it doesn't need to be bespoke syntax. Enum values are already objects from the point of view of the compiler. Just give them a str member. This is similar to how in Rust built-in integers also have members. It's not bespoke, it's using already-existing syntax for objects and extrapolating it to other types. Another alternative that wouldn't involve bespoke syntax would be giving enum values an operator const char *() overload, either explicit or implicit.

>Converting enums to strings is one use case for reflection. Do you suggest introducing bespoke syntax for the other use cases too?

The other cases are pretty much all variations of enumerating members of a class. I have no problem with those examples, since it's basically how it's done everywhere. You get a meta object for the type that a function that enumerates the members of the type, and you go through it.

Re: Reflection for C++26

#176

Post by fluoridation »

coopierez wrote: post #77
j16sdiz wrote: post #51

Earlier quoted context omitted.

This is how C++ language usually works. Just some primitive for building libraries on. Expect some library change come later.

Thankfully it is so easy to quickly import libraries into C++...

This would be the standard library so it's not really an issue.

Re: Reflection for C++26

#177

Post by binary132 »

naertcxx wrote: post #98
qalmakka wrote: post #66

While I love this paper and this proposal in general, as a C++ developer every time C++ adds a new major feature I get somewhat worried about two things: 1. how immense the language has become, and how hard it got to learn and implement 2. how "modernising" C++ gives developers less incentives to convince management to switch to safer languages While I like C++ and how crazy powerful it is, I also must admit decades…

I think the focus on smart pointers is a huge mistake. Code bases using shared_ptr inevitably will have cycles and memory leaks, and no one understands the graphs any more. Tree algorithms that are simple in literature get bloated and slow with shared_ptr. The only issue with pointers in C++, which C does not have , is that so many things are copied around by default if one is using classes. So the way to deal with t…

It is always weird to me when people have a big problem with C++ smart pointers but think that Rust smart pointers are the bee’s knees.

It is just a different syntax for the same thing.

I honestly think people just find the words “unique ptr” scary or syntactically overwhelming. If that is true, fortunately we also have using aliases :)

Re: Reflection for C++26

#178

Post by binary132 »

Zambyte wrote: post #136
oldpersonintx wrote: post #90

Earlier quoted context omitted.

There is no alternative to modernizing C and C++ Indeed I wish they were even more aggressive about breaking changes Rust is nifty but there is simply too much existing C/C++ out there and "rewrite it in Rust" is not a serious suggestion Maybe one day we have some cool AI that magically rewrites old C/C++ automatically, but by then I also assume we will have AI-designed languages Until then, we need C/C++ to be maint…

Thoughts on Zig? Just not popular enough to fit the bill or are there technical reasons? I bring it up partially because they are not taking a "rewrite it in Zig" approach, they are specifically aiming for incremental migration in mixed C / Zig codebases.

IMO zig is neat but not that much different (for better or for worse) than C and C++. I do really like the comptime concept and wish C had it, and I like it that allocators are explicit in interfaces. There are other things I don’t like about it and I don’t think it has much chance to supplant C or C++.

Re: Reflection for C++26

#179

Post by kccqzy »

account42 wrote: post #128
kccqzy wrote: post #58

Earlier quoted context omitted.

It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.

It does significantly speed up clean builds in many cases, to the point that those clean builds can even be faster than many "incremental" builds in some cases.

I do not know of any compiler that can compile different parts of a translation unit in parallel. But plenty of systems (including the venerable `make -j`) can compile separate translation units in parallel because they are independent.

Re: Reflection for C++26

#180

Post by kccqzy »

zarzavat wrote: post #121
kccqzy wrote: post #58

Earlier quoted context omitted.

It's a cute idea but just not scalable. It doesn't speed up compilation because separate translation units can be compiled independently and cached.

Do things that don’t scale :) Obviously it’s not suitable for dev builds, I don’t think anyone uses it for that. For release builds you would want to clear caches anyway.

You don't want to clear caches for release builds. That just makes release builds unnecessarily slow and impedes the flow of Continuous Deployment. You just need to have separate caches for different build flags, including a dedicated cache for release builds.
Post reply on HN