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

181–190 of 214 posts

Re: Reflection for C++26

#181

Post by steveklabnik »

binary132 wrote: post #177
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…

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

There are significant differences between the two, even if they are similar at a high level.

But also, pointing out problems doesn’t mean that something is useless. Something can be a net good, yet still have downsides.

Re: Reflection for C++26

#182

Post by kragen »

CuriousCosmic wrote: post #169
AnimalMuppet wrote: post #150

Earlier quoted context omitted.

LOL. What used to be a typo is now becoming valid syntax (and of course the compiler can't warn you because it's now valid). Ouch. At least an old compiler saved you...

Tbh this is why you need to set the C++ std version when you compile. Don't just assume the default for the compiler but hard lock it at a specific version so you can know which compilers you can support and compilers can warn you if you use new features.

i set it to c++20 on purpose, i just didn't know the feature existed (and didn't know that my clang didn't support that feature; i'm a little uncertain as to whether my clang is an outdated version without full c++20 support, or whether gcc is implementing a proposed extension that didn't actually make it in)

Re: Reflection for C++26

#183

Post by meindnoch »

maccard wrote: post #173
meindnoch wrote: post #171

Earlier quoted context omitted.

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

So you're saying that turning std::span from a standard library class into a language feature wouldn't break the ABI? How so? How would such a language construct fit into the existing ABI?

(for context: parent is referring to the fact that x64 calling conventions mandate structs larger than 64 bits to be passed in memory, which means that passing a 128bit std::span is going to be less efficient than passing a separate 64bit index and 64bit length, as those can go into registers)

Re: Reflection for C++26

#184

Post by kragen »

chipdart wrote: post #166
kragen wrote: post #134

Earlier quoted context omitted.

marshall cline's c++ mini-faq is a list of about 100 pages of them from the 01990s

> marshall cline's c++ mini-faq (...) Published in 1994. Literally 30 years ago, years before there was even anything resembling a C++ standard. I'm not sure why you thought it's relevant.

it was actually originally published in 01991 (at which point it was just the comp.lang.c++ faq), but cline continuously updated the faq-lite until 02012†; see the update history at https://web.archive.org/web/20140225204048/http://www.parash.... so it's entirely your choice to only look at a version of it from 01994; you can easily find him merrily celebrating c++'s boneheaded design errors continuously after c++98, after c++03, and indeed after c++11, although the document was looking increasingly old-fashioned

however, even if we only consider the 01994 version, i still extensively disagree with your comment, and i will explain why in detail

in fact c++ was already well defined before ansi formed their committee in 01990, four years before the version of that faq that you chose to read. the arm (not the arm arm, the annotated reference manual) was the standard standard until c++98, and it's written as one. it says things like

> The following rule limits the context sensitivity of the rewrite rules for inline functions and for class member declarations in general. A class-name or a typedef-name or the name of the constant used in a type name may not be redefined in a class declaration after being used in the class declaration, nor may a name that is not a class-name or a typedef-name be redefined to a class-name or a typedef-name in a class declaration after being used in the class declaration. For example,

(that's from §9.9 if you want context)

but why would it be relevant whether there was a c++ standard or not? it would be relevant if the problems documented in the 01994 version of the faq-lite had been eliminated by standardization. but that is comprehensively not the case. every single one of the misconceived features in the 01994 version of the faq-lite is still in everything resembling a c++ standard, so all the pitfalls of poorly interacting features it documents are still relevant today. that's why i think that even the 01994 version of the faq-lite is relevant

so from my point of view it is not only wholly false to say that there was nothing resembling a c++ standard in 01994, it is also irrelevant whether there was anything resembling a c++ standard when the faq-lite was written (at least for 01994 and later versions)

furthermore, your particular choice of 01994 is unjustifiable and evidently only serves to provide a spurious veneer of justification for your irrelevant objection that (interpreting you generously) the faq-lite predates the c++98 standard. if you thought that was important you should have picked a version of the faq-lite from 01999 to criticize

______

† after a hiatus, since 02019, it is again being updated at https://www.parashift.com/c++-faq-lite/ but obviously the new center of gravity for this kind of thing is stack overflow and cppreference

Re: Reflection for C++26

#185

Post by meindnoch »

fluoridation wrote: post #175
meindnoch wrote: post #163

Earlier quoted context omitted.

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

So your problem is that C++ prefers free functions instead of these pseudo-members?

Because other than the free function vs member access thing, I don't see why it would concern the user of `enum_to_string()` that it's a proper function instead of a keyword like `static_assert`...

Re: Reflection for C++26

#186

Post by npoc »

tsimionescu wrote: post #91
npoc wrote: post #85

Earlier quoted context omitted.

Just because it's newer doesn't make it better. There are good reasons for avoiding iostream

That's my point - iostream is a really bad piece of code, and if you're anyway going to use modern C++, it's really recommended to stop using it.

Sorry, I got your comment completely backwards

Re: Reflection for C++26

#187

Post by beached_whale »

germandiago wrote: post #115
beached_whale wrote: post #64

Earlier quoted context omitted.

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.

Should be able to build that on if it isnt there. But at runtime the type would need to be a sum type like variant.

Re: Reflection for C++26

#188

Post by bdd8f1df777b »

beached_whale wrote: post #63
bdd8f1df777b wrote: post #52

Earlier quoted context omitted.

What I commonly need is JSON serialization/parsing directly with structs.

They exist, for instance https://github.com/beached/daw_json_link , uses mappings of JSON class members/construction. It handles a bunch of types out of the box and allows custom types to be mapped. Also, it integrates with some of the reflection like libraries out there now(Boost.Describe/Boost.PFR) and will be trivial to add C++26 static reflection when available. Because the library doesn’t need to allocate unless…

Without static reflection, we need to write a lot of boilerplate code, and those boilerplate is not guaranteed to stay in sync with the struct definition. That is why static reflection is sorely needed.

Re: Reflection for C++26

#189

Post by CuriousCosmic »

kragen wrote: post #182
CuriousCosmic wrote: post #169

Earlier quoted context omitted.

Tbh this is why you need to set the C++ std version when you compile. Don't just assume the default for the compiler but hard lock it at a specific version so you can know which compilers you can support and compilers can warn you if you use new features.

i set it to c++20 on purpose, i just didn't know the feature existed (and didn't know that my clang didn't support that feature; i'm a little uncertain as to whether my clang is an outdated version without full c++20 support, or whether gcc is implementing a proposed extension that didn't actually make it in)

Yeah, I think gcc has a std c++20 mode as well as a with extensions mode. And adding `-pedantic` helps because it forces extensions (unless specified in the std type) and non-conformant code to be rejected.

And that clang likely just didn't have full c++20 support. Which tbf I actually don't think any clang has full c++20 support currently as even bleeding edge clang still is missing a few things in the lang and library departments.

Re: Reflection for C++26

#190

Post by beached_whale »

bdd8f1df777b wrote: post #188
beached_whale wrote: post #63

Earlier quoted context omitted.

They exist, for instance https://github.com/beached/daw_json_link , uses mappings of JSON class members/construction. It handles a bunch of types out of the box and allows custom types to be mapped. Also, it integrates with some of the reflection like libraries out there now(Boost.Describe/Boost.PFR) and will be trivial to add C++26 static reflection when available. Because the library doesn’t need to allocate unless…

Without static reflection, we need to write a lot of boilerplate code, and those boilerplate is not guaranteed to stay in sync with the struct definition. That is why static reflection is sorely needed.

Even static reflection isn’t a panacea and we have it now the libraries like PFR that give us a reference and name of each member for aggregates. But this is the same problem for anything else using those types too. For non-aggregates we need reflection or some manual library.

I am not disagreeing, just more saying what we have now.

Post reply on HN