More information for 'meta::member' and meta::function.

[MineBill]

Recently, i've been making more progress with my project and i decided to use Angelscript. I thought i could use the information registered with meta but i quickly encountered an issue: When registering the member fields of a type with Angelscript, you have to provide the offsets to the members but as far as i can tell, that information is not available.

I don't know how hard or even possible it is to get this information with the current registration interface so i'm only making a suggestion here.

Additionally, it would be helpful if we could get the raw pointer to functions registered with function_, for similar reasons.

[BlackMATov]

I was thinking about an interface like this:

struct listener {
    template < typename Class >
    static void on_class() {}

    template < typename Class, typename Member >
    static void on_class_member(meta::member member, Member member_ptr) {}

    template < typename Class, typename Method >
    static void on_class_method(meta::method method, Method method_ptr) {}
};

meta::class_<ivec2, listener>()
    .member_("x", &ivec2::x)
    .member_("y", &ivec2::y)
    .method_("length2", &ivec2::length2);

But I don't like it (because it's inconvenient). I accept any suggestions on how to make something like this better!

Additionally, it would be helpful if we could get the raw pointer to functions registered with function_, for similar reasons.

I can return raw pointers to methods/members from meta::method/meta::member, but they will be in uvalue which makes them a bit useless (because without a static type they will be hard to extract).

[MineBill]

I can't come up with good suggestions on how to implement this, but in an ideal world, there exists a meta::member::get_offset function that returns a std::size_t which is equal to offsetof(TheStructMemeberComesFrom, the_member_name). I thought this might not be possible, since you can't really use offsetof on member pointers, until i found this article, however i'm not sure if the way it does it is good enough.

About the raw pointers, why does it have to be a uvalue is that a limitation or a safety feature?

[BlackMATov]

About the raw pointers, why does it have to be a uvalue is that a limitation or a safety feature?

I can return typed raw pointers when registering with an interface like the one shown above (member_ptr, method_ptr are typed raw pointers).

At the meta::method/meta::member level, I can't return a typed(!) pointer because type erasure has occurred, and they can be returned only wrapped in dynamic storage, which is what uvalue is.

[MineBill]

Yes, i'm really sorry for not being more explicit. I actually just want a void* and only now i just remembered that you can get that from uvalue so returning uvalues is perfectly fine.

[BlackMATov]

Just merged raw pointer api access (get_pointer method in method/member/variable/function classes) but i'm still thinking about registration listeners.

[MineBill]

I'm not sure either. They could probably be used to calculate the offsets but then i'd need somewhere to store them and it would probably take more code than just using metadata and offsetof. Maybe they could be useful elsewhere but not in this instance.

[BlackMATov]

Unfortunately, I can't provide offset for members and methods in general case because the library supports virtual hierarchy. But, you can calculate offset for your case and store it to methods/members metadata!

Also, I'm going to revert my previous merge with raw pointers. I think it's redundant information that can be stored to metadata too :-)

P.S.

Registration listeners can be used well to bind scripting languages, but I'm not sure when I'll get around to it and come up with a good API.