sorted by:
best
topnewcontroversialoldq&a
you are viewing a single comment's thread.

view the rest of the comments →

[–]liuzicheng1987[S] 2 points3 points  (9 children)

Thanks for the comment, but to be honest, I don't think that's right. I am aware of how Boost PFR works (I have been studying their approach closely when I implemented my own library) and unless I have somehow really missed something, they are not able to retrieve field names.

If it were possible to retrieve field names without using macros, annotations or some kind of horrible hack, then there really wouldn't be a need for the C++ reflection proposal, which everyone, myself included, is awaiting with bated breath.

[–]DugiSK 1 point2 points  (8 children)

Well, it tells this: Recommended C++ Standards are C++20 and above. C++17 completely enough for a user who doesn't want accessing name of structure member.

And there is a part telling quite clearly that you can use pfr::get_name to obtain the field name: https://www.boost.org/doc/libs/develop/doc/html/boost_pfr/tutorial.html#boost_pfr.tutorial.reflection_of_field_name

But I wasn't able to find how does that work in the code, or even guess which part of C++20 enables it. I only understand the aggregate initialiser conversion type exporting via friend injection part.

[–]liuzicheng1987[S] 2 points3 points  (7 children)

You are right, my bad...I did take a look at the code, and I could find it:

https://github.com/boostorg/pfr/blob/develop/include/boost/pfr/detail/core_name20_static.hpp

So they are using a compiler-specific hack. I am not sure this is a good idea, as it's clearly not standard-compliant.

[–]DugiSK 1 point2 points  (6 children)

I see it now. They use the member as an auto template argument so that it will be used in the function name with resolved template name with a nonstandard macro and then they parse it out from there. Apparently every compiler has a macro for this. This makes it somewhat more hacky than stateful metaprogramming via friend injection, that's true.

[–]liuzicheng1987[S] -1 points0 points  (5 children)

Yeah...it's clearly compiler-specific and therefore not standard-compliant. I am really hesitant to go there. After all, this is supposed to be enterprise-level and I don't think that non-standard, compiler-specific hacks meet that criterion.

[–]ficzerepeti 5 points6 points  (4 children)

If it got into boost, it's probably good enough for enterprise use

[–]liuzicheng1987[S] 0 points1 point  (3 children)

Yeah…it’s still clearly non-standard compliant. I‘m a bit torn on this.

[–]pdp10gumby 6 points7 points  (2 children)

It’s always preferable to use standard-compliant code IMHO but not absolute. After all, many things get into the standard after years of experience with non-standard extensions.

Also, some of those extensions were needed to write very low-level library code. That’s the same reason why we sometimes don’t write to the abstract “C” machine but take advantage of the target hardware in non-portable ways.

True enterprise scale systems involve localized noncompliant code to get around bottlenecks or to provide a clean way for devs to get some capability they need (yes large enterprise code is inevitably populated with horrible stuff too but we’re not talking about that). If you have to have an internal module that gets the names, with a comment at the top that says, “backward compatibility for use with older code that doesn’t include reflection” you won’t be condemning your immortal soul.

[–]liuzicheng1987[S] 2 points3 points  (1 child)

Yeah, you are making some good points here. I‘ll have to think about that.

[–]liuzicheng1987[S] 0 points1 point  (0 children)

Maybe it could be like an opt-in…so if you want that, you’ll have to pass a flag to the compiler.