veselink1/refl-cpp

Access member descriptor from pointer-to-member

W4RH4WK opened this issue · 4 comments

I've been wondering: is there an easy way to access the descriptor of a specific member directly, rather than looping over all members.

Something like:

struct Foo {
  int x, y;
};

REFL_TYPE(Foo)
REFL_FIELD(x)
REFL_FIELD(y)
REFL_END

int main()
{
  auto member = refl::reflect_member(&Foo::y);

  if constexpr (has_attribute<SomeAttribute>(member)) {
    // do something with attribute
  }
}

Hey there 👋,

There is currently no provision for a field descriptor lookup given a pointer to a member, however, one can be added if it's going to be useful, which it seems to be 👍.

To provide some background: I am trying to build a serialization framework where types can be automatically serialized via reflection (as fallback), but the user can still customize the serialization of a specific type by using template specialization.

It would be nice if attributes (or more generally the descriptor) can still be accessed from this customized serialization function.
For my use-case, the attributes will contain information that is helpful for the serialization process (e.g. upper/lower bounds on a numeric member).

My first idea for implementing this would be by using filter on the members of the type's descriptor, comparing the pointer-to-member. Yet, I am unsure how to reduce from the type list to single (optional) element.

Note that there is absolutely no hurry. I am just toying around with a pet project.

Ah, that makes sense. Have you considered refl::util::find_one, which returns the matching descriptor and fails if the list doesn't contain a match?

Something like

template <typename T, typename C, T C::*P>
auto find_field_impl() {
    return refl::util::find_one(field_descriptors_of<C>{}, [](auto m) { return m.pointer == P; });
}

https://godbolt.org/z/je3oxc6Wc

Sorry for the late reply. I missed find_one.

The example looks good! Just noticed a typo in line 11, reflect should take C as template parameter not T; unless I misunderstood something.

A bit sad that the additional type traits are necessary, but I guess there are already a lot of custom type traits in the library.
Do you have any plans for adding this functionality for fields and functions / properties in a future release?