Coulée entre void * et un pointeur vers la fonction membre

Question

Je suis actuellement en train d'utiliser GCC 4.4, et j'ai beaucoup de casse-tête entre void * et un pointeur vers la fonction membre. Je suis en train d'écrire une bibliothèque facile à utiliser pour la liaison des objets C++ à un interprète Lua, comme ceci:

LuaObject<Foo> lobj = registerObject(L, "foo", fooObject); 
lobj.addField(L, "bar", &Foo::bar); 

J'ai la plus grande partie fait, à l'exception de la fonction suivante (qui est spécifique à une certaine signature de la fonction jusqu'à ce que j'ai une chance de le généraliser):

template <class T> 
int call_int_function(lua_State *L) 
{ 
    // this next line is problematic 
    void (T::*method)(int, int) = reinterpret_cast<void (T::*)(int, int)>(lua_touserdata(L, lua_upvalueindex(1))); 
    T *obj = reinterpret_cast<T *>(lua_touserdata(L, 1)); 

    (obj->*method)(lua_tointeger(L, 2), lua_tointeger(L, 3)); 
    return 0; 
} 

pour ceux qui ne connaissent pas Lua, lua_touserdata(L, lua_upvalueindex(1)) obtient la première valeur associée à une fermeture (dans ce cas, il est le pointeur de fonction membre) et le retourne comme vide *. GCC se plaint que void * -> void (T :: *) (int, int) est une distribution invalide. Des idées sur la façon de contourner cela?

Answer 1

Vous cannot cast a pointer-to-member to void * ou tout autre type de pointeur "normal". Les pointeurs vers les membres ne sont pas des adresses comme les pointeurs réguliers. Ce que vous devrez probablement faire est d'envelopper votre fonction de membre dans une fonction régulière. La FAQ C++ Lite explains this dans certains détails. Le problème principal est que les données nécessaires pour implémenter un pointeur vers un membre ne sont pas seulement une adresse, et en fait varies tremendously basée sur l'implémentation du compilateur.

Je présume que vous avez le contrôle sur ce que les données utilisateur lua_touserdata renvoie. Cela ne peut pas être un pointeur vers un membre, car il n'y a pas de façon légale de récupérer cette information. Mais vous avez d'autres choix:

• Le choix le plus simple est probablement d'envelopper votre fonction membre dans une fonction gratuite et de retourner cela. Cette fonction libre devrait prendre l'objet comme premier argument. Voir l'exemple de code ci-dessous.

• Utilisez une technique similaire à celle de Boost.Bind's mem_fun pour renvoyer un objet fonction, que vous pouvez modéliser de façon appropriée. Je ne vois pas que c'est plus facile, mais cela vous permettrait d'associer plus d'état avec la fonction return si vous en aviez besoin.

est ici une ré-écriture de votre fonction en utilisant la première façon:

template <class T> 
int call_int_function(lua_State *L) 
{ 
    void (*method)(T*, int, int) = reinterpret_cast<void (*)(T*, int, int)>(lua_touserdata(L, lua_upvalueindex(1))); 
    T *obj = reinterpret_cast<T *>(lua_touserdata(L, 1)); 

    method(obj, lua_tointeger(L, 2), lua_tointeger(L, 3)); 
    return 0; 
} 

Answer 2

Pour contourner ce problème étant donné les restrictions de la coulée d'un pointeur à fonction membre à void* vous pouvez envelopper le pointeur de fonction un petit tas alloué struct et de mettre un pointeur sur cette struct dans vos données utilisateur Lua:

template <typename T> 
struct LuaUserData { 
    typename void (T::*MemberProc)(int, int); 

    explicit LuaUserData(MemberProc proc) : 
     mProc(proc) 
    { } 

    MemberProc mProc; 
}; 

LuaObject<Foo> lobj = registerObject(L, "foo", fooObject); 
LuaUserData<Foo>* lobj_data = new LuaUserData<Foo>(&Foo::bar); 

lobj.addField(L, "bar", lobj_data); 

// ... 

template <class T> 
int call_int_function(lua_State *L) 
{ 
    typedef LuaUserData<T>      LuaUserDataType; 
    typedef typename LuaUserDataType::MemberProc ProcType; 

    // this next line is problematic 
    LuaUserDataType* data = 
     reinterpret_cast<LuaUserDataType*>(lua_touserdata(L, lua_upvalueindex(1))); 
    T *obj = reinterpret_cast<T *>(lua_touserdata(L, 1)); 

    (obj->*(data.mMemberProc))(lua_tointeger(L, 2), lua_tointeger(L, 3)); 
    return 0; 
} 

Je ne suis pas avertis avec Lua donc j'ai probablement oublié quelque chose dans l'exemple ci-dessus. Gardez à l'esprit, aussi, si vous suivez cette route, vous devrez gérer l'allocation de LuaUserData.

Answer 3

Il est possible de convertir le pointeur aux fonctions membres et attributs à l'aide des syndicats:

// helper union to cast pointer to member 
template<typename classT, typename memberT> 
union u_ptm_cast { 
    memberT classT::*pmember; 
    void *pvoid; 
}; 

Pour convertir, mettre la valeur source dans un membre, et tirer la valeur cible de l'autre.

Bien que cette méthode soit pratique, je ne sais pas si cela va fonctionner dans tous les cas.

Answer 4

Contrairement à l'adresse d'une non statique fonction membre, qui est un type pointeur à membre d'une représentation complexe, l'adresse d'une fonction membre statique est généralement juste l'adresse de la machine, compatible avec une conversion à void *.

Si vous devez lier une fonction membre C++ non statique à un mécanisme de rappel de type C ou C basé sur void *, vous pouvez écrire un encapsuleur statique à la place.

L'emballage peut prendre un pointeur vers une instance comme argument, et passer le contrôle à la fonction membre non statique:

void myclass::static_fun(myclass *instance, int arg) 
{ 
    instance->nonstatic_fun(arg); 
} 

Answer 5

Ici, il suffit de changer les paramètres de la fonction void_cast pour qu'il corresponde à vos besoins:

template<typename T, typename R> 
void* void_cast(R(T::*f)()) 
{ 
    union 
    { 
     R(T::*pf)(); 
     void* p; 
    }; 
    pf = f; 
    return p; 
} 

exemple d'utilisation:

auto pvoid = void_cast(&Foo::foo);