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

111–120 of 214 posts

Re: Reflection for C++26

#111

Post by account42 »

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…

shared_ptr isn't the only smart pointer and definitely shouldn't be used for everything. The default should be unique_ptr which is simple to reason about and a huge improvement over only having raw pointers that may or may not be owning what they point to.

Re: Reflection for C++26

#113

Post by gpderetta »

chipdart wrote: post #108
account42 wrote: post #107

Earlier quoted context omitted.

Personally I'd rather the comitte take longer and require more implementation experience before accepting new features. There are still too many half-baked ideas that turn out to be mistakes afterwards, resulting in either needless breaking changes or being stuck with bad solutions. This is especially true for library features where users can always use third party libraries for containers/algorithms that are yet to…

> There are still too many half-baked ideas that turn out to be mistakes afterwards (...) Care to point an example?

Some examples on top of my mind:

- export templates is the canonical one.

- Universal references are a great feature in principle, but the way they are integrated in the language is far from ideal.

- Both features are great in isolation, but the interaction between initializer lists and aggregate initialization is a giant footgun.

- Coroutines are overly complex and still incomplete but I still have hope.

- Modules feel DOA so far.

- Unrestricted compile time evaluation is great, but the constexpr qualifier per se doesn't guarantee any useful property.

edit: overall I'm happy with the evolution of the language, but the standardization process has flaws

Re: Reflection for C++26

#115

Post by germandiago »

beached_whale wrote: post #64
germandiago wrote: post #53

Earlier quoted context omitted.

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

Boost.PFR is really neat and doesn’t need manual mapping for aggregate types

What I needed is accessing thosr by name. So PFR won't do.

Re: Reflection for C++26

#116

Post by aslmq »

account42 wrote: post #111
naertcxx wrote: post #98

Earlier quoted context omitted.

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…

shared_ptr isn't the only smart pointer and definitely shouldn't be used for everything. The default should be unique_ptr which is simple to reason about and a huge improvement over only having raw pointers that may or may not be owning what they point to.

unique_ptr is often too restricted. If you have a simple tree with unique_ptr, already the back edges need to be raw pointers to avoid cycles.

If you add an iterator, the iterator needs internal pointers to the nodes, so by definition the node pointers are not unique. Again, raw pointers are better.

I have never seen a complex data structure where unique_ptr is really used.

Re: Reflection for C++26

#117

Post by cb321 »

lallysingh wrote: post #22

Wow this got really long. I was one of the coauthors for a reflection proposal (N3340) over a dozen years ago. Implementing compile-time reflection is honestly trivial - you basically transfer data from the symbol table on-demand into template specializations. It was roughly 1500 LOC to modify g++ to do it. Looking at the examples ( https://isocpp.org/files/papers/P2996R4.html#examples ) what really stands out is the…

I think another good example might be extracting function signatures (parameter names & types, default values -- if any) at compile-time for various purposes.

Re: Reflection for C++26

#118

Post by gpderetta »

Slyfox33 wrote: post #99
naertcxx wrote: post #98

Earlier quoted context omitted.

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…

You actually think managing memory manually using new and delete is easier than dealing with occasional problems with leaking memory using shared_ptr? That seems pretty ridiculous to me.

naertcxx point is that you shouldn't use shared_ptr for your next ptr in your list (or other node based container) node. It is slow and error prone. Instead the list container itself should own the nodes and delete them on container destruction. I think it is a good point. unique_ptr is better, but still not always ideal.

Re: Reflection for C++26

#119

Post by gpderetta »

naertcxx wrote: post #100
pjmlp wrote: post #83

Earlier quoted context omitted.

While I share the feeling, I don't feel that my daily languages (Java, C#, TypeScript) are getting that far behind. Even Go is rediscovering that staying simple just doesn't happen for any language that gets industry adoption at scale.

I agree with this. Python is now more complex than C++. Python looks as if it is simple, because the syntax looks clean. If you read the new "compilers" [1] in packages like PyTorch, which are unfortunately written in Python, you stare at a huge code base with walls of text, objects calling one another in a maze of ravioli code and generally no help at all to make sense of it all. Compare that to the gcc code bases,…

I very much have a love/hate relationship with python, but it does have a significantly milder ramp for beginners. The complexity is relatively well hidden. I can recommend python as a first language to someone that wants to learn to program. I can't do that with C++ with a straight face, unless one is especially interested in the areas were C++ still dominates.

Re: Reflection for C++26

#120

Post by gpderetta »

utensil4778 wrote: post #59
stefanos82 wrote: post #14

Can I ask a naive question that consists of two parts and please don't flame me? lol * What type of problems static reflection could solve, in general? * Are there specific cases and / or situations where static reflection could resolve such case, even simplify an unnecessary complexity?

Maybe this doesn't count as static, but I used to regularly use reflection in C# to generate code for interacting with foreign DLLs. This was a video game mod, essentially. I needed to create a text interface to modify settings for any other mod that might be installed. Other mods would simply implement a settings class with certain attributes, then I could list out all fields and their types. The list was processed…

C# also has the compiler available at run time, which is an extremely powerful feature, so the line between static and dynamic reflection is blurred.
Post reply on HN