Get variable name from meta object

[sybalos]

Hi!

I'm looking at the reflection system test code and documentation. Is there a way to iterate over an object member variable and get all the variable name (as string) ? I did figure out how to do it with values but not with names. Trough the registered hashed_string maybe ?

[Green-Sky]

I think you are supposed to use the Properties for that.
https://github.com/skypjack/entt/wiki/Crash-Course:-runtime-reflection-system#properties-and-meta-objects
and I am afraid, that you have to name them yourself. I use the dreaded macros for that.

[skypjack]

Iterate over meta data members is quite easy actually:

for(auto data: type.data()) {
    // ...
}

As for the variable names, EnTT doesn't attach this kind of information by default. However, you can use a property for that as suggested by @Green-Sky since they're literally meant for that. 👍

[mathisloge]

@skypjack I'm currently a bit lost about this.
My use case would be to get all type names, and channel them through to an inspector app. So you could inspect each type and see the name: value and make adjustments if the value is readable.

Currently I have a converter function which maps each type the the protocol version. However I would really like to just depend on the registered types and use the meta_any::type().is_* functions to determine the serialization.

Given the following code, what would be the most entt way of doing such things, since I would need to save each attribute of the type. Would it be "good" to use the custom or function field which returns a vector with all the names of methods, functions etc.?

struct TestRect
{
    int x;
    int y;
    int width;
    int height;
};
 entt::meta_factory<TestRect>(context)
        .type("TestRect"_hs)
        .data<&TestRect::x>("x"_hs)
        .data<&TestRect::y>("y"_hs)
        .data<&TestRect::width>("width"_hs)
        .data<&TestRect::height>("height"_hs);
   
entt::meta_any data_type = TestRect{};
    for(auto&& data : data_type.type().data()) {
        entt::meta_any x = data.second.get(data_type);
        std::println("Value {}={}", <<get_name_here>>, x);
    }
}

[Innokentiy-Alaytsev]

If nothing has drastically changed in the past years, the answer is the same: attach to every meta-item, including type itself (I believe it's possible), a property that holds it's name.

[mathisloge]

But that's the part I'm not quite get, the wiki doesn't really mention how to attach a property to a data member.

[Innokentiy-Alaytsev]

Apparently, it did change in the past years. If I understand correctly, now you have not properties, but traits and custom data.

[skypjack]

Yeah, there are no properties anymore. You can have them if you like by setting a map as custom data, ofc.
However, I suggest using an app specific custom data structure where you set the data of interest for you, rather than a generic map.
This test file and this part of the doc is where you want to start from probably.

[lucaspcamargo]

I have tried to use const char* as the custom data type. When trying to retrieve the data, the returned pointer is always null:

    // on reflection setup
    entt::meta_factory<nb::render>{rtti::ctx_systems()}
        .custom<const char *>("render_simple")
        .type("render_simple"_hs)
        .[...]
    // later...
    entt::meta_type type = entt::resolve(rtti::ctx_systems(), hashval);
    const char *type_name = type.custom();
    log::info("[system_factory] got type %x (%s)", type.id(), type_name); 
    // correct type is found, but type_name is alway null here :(

I suppose this is a side-effect of how entt::meta_custom has a special case for pointer types. entt::meta_factory::custom<>() stores the custom data tagged with type_id<const char*>, but the pointer specialization for entt::meta_type::custom compares it against type_id<const char>. Ok then.

For now I have side-stepped the issue by wrapping my strings with a struct, like this:

struct str {
    const char * _val;
    
    str (const char * strptr) : _val (strptr) {}
    
    operator const char *() const 
    { 
        return _val;
    }
    bool operator == (const char *other) const
    {
        return !strcmp(other, _val);
    }
};

This is totally workable and fine. I was just wondering if there is a better way to do it. Or if I should just keeping using structs for custom data, since right now a simple string would suffice but this may not always be the case.

[skypjack]

Technically speaking, your T is const char *. Therefore, if you want to try cast the custom data, you should use const char **. That is, T *. This is one of the types you can cast the opaque object to: [const] T * and [const] T &. 👍
That said, note that custom data are stored in a std::shared_ptr<void> and deleted automatically when the context is destroyed.
I feel like statically allocated strings wouldn't work well in this sense, even if you decided to use the right type (which you didn't).

[lucaspcamargo]

Oh, I see, if I had used const char ** and try_cast, this should not be a problem. Raw, statically allocated strings would be easy to use, but after thinking more about it, I have to agree. It is semantically weird for the meta system, it is better when it owns all of its data directly.

For now I decided to use standardized structs with fixed-sized char arrays. In this sense I keep the meta data close together and avoid constant pointer chasing when interacting with the meta system. Having a maximum identifier length is not a huge issue, 32 bytes should be enough for everyone :)

Thank you so much for your advice! Here's hoping this was on-topic for this thread.