Discussion :

[Narann]

Salut � tous,

Je bosse actuellement sur l'UI windows de mupen64plus (pour ceux qui connaissent).

Je rencontre une difficult� avec les conversion de type...

Je vous explique, voici une fonction C tir� de l'UI console du projet:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
void * osal_dynlib_getproc(m64p_dynlib_handle LibHandle, const char *pccProcedureName)
{
    if (pccProcedureName == NULL)
        return NULL;
 
    return GetProcAddress(LibHandle, pccProcedureName);
}

GetProcAddress renvoit donc un void*.

Quand on compile en Visual Studio (le projet windows est en Visual Studio), �a fonctionne. Pas de probl�mes.


Moi je bosse sur l'interface graphique qui est en Qt4. J'utilise donc qmake et mingw32-make pour compiler.

Nous avons besoins, pour cette UI de faire grosso mode la m�me chose que pour l'interface console: Charger la lib mupen64plus.dll, qui contient le "core" de l'�mulateur.

Voici la m�thode:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
void * LibraryLoader::resolve(const char * name)
{
    if (!private_->pluginHandle)
        return 0;
 
    return GetProcAddress(private_->pluginHandle, name);
}

Avec comme d�finition pour pluginHandle:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

m64p_dynlib_handle pluginHandle;

Et l�, �a crash avec �a comme message:

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

src\libraryloader_win32.cpp:34: error: invalid conversion from 'int (*)()' to 'void*'

En lisant la doc msdn: http://msdn.microsoft.com/en-us/libr...=VS.85%29.aspx
Il est pr�cis� que GetProcAddress renvoit l'adresse de la fonction ou variable export�.
Serait-ce une subtilis� du compilo?

Visual Studio renverrait bien l'adresse (�a expliquerai pourquoi l'UI console compile sans probl�me), et mingw32 renverrait un int? C'est possible �a?

Si l'un d'entre vous pourrait �clairer la lanterne? Parce que l� je suis dans l'impasse.

Merci d'avance et bonne journ�e � tous!

[NoIdea]

Le message me semble plutot claire :
La conversion entre l'adresse de la fonction (qui doit �tre du type int ()) et un void* n'est pas accept�e. Visual Studio doit faire cette conversion implicitement mais g++ demande un cast.

De plus, il me semble que la norme ne garantit pas la conversion d'un pointeur de fonction vers un void* bien que g++ l'accepte.

Pourquoi ne pas d�finir ta fonction comme renvoyant un int(*)() ?

Bien sur, si tu souhaites que ton code compile sur Visual et mingw ou g++, tu peux aussi faire :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
 
return (void*)GetProcAddress(private_->pluginHandle, name);

ou encore :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

return static_cast<void*>(GetProcAddress(private_->pluginHandle, name));//Ou reinterpet cast (je ne sait jamais).

[Narann]

Hello! Tout d�ja merci pour cette r�ponse! Je vais regarder comment on fait un cast (d'ailleurs si tu avais grosso modo la ligne que �a pourrait donner...)

De plus, il me semble que la norme ne garantit pas la conversion d'un pointeur de fonction vers un void* bien que g++ l'accepte.

Bon, dans les fait c'est un HMODULE, mais �a ne r�sout pas mon soucis.

Pourquoi ne pas d�finir ta fonction comme renvoyant un int(*)() ?

Haha et c'est la que c'est dr�le (ou pas...). La d�finition des proc�dure de chargement des dynlibs sont communes entre Unix et Windows... C'est juste que dans mon .pro (QT) j'ai (en gros):

HEADERS += include/libraryloader.h
unix:SOURCES += src/libraryloader_unix.cpp
win32:SOURCES += src/libraryloader_win32.cpp

�a marche sous Linux. Et sous Windows (Visual Studio) aussi. Mais pas avec mingw32-make...

EDIT: Je suis en train de pr�visualis� mon message et je vois que tu a �dit� le tiens avec un exemple.

Je vais le tester et je te redis, merci beaucoup!

[Narann]

Bon:

return static_cast<void*>(GetProcAddress(private_->pluginHandle, name));

Ne fonctionne pas.

Par contre, avec :

return (void*)GetProcAddress(private_->pluginHandle, name);

�a compile!

Le soucis c'est que �a se lance mais �a crash windows. Etant sous QT + MinGW, je suis incapable de d�bugger le truc. va falloir que j'y aille au printf...

M�me si j'ai un probl�me, on peut dire que le sujet est r�solu...

Merci beaucoup!

[3DArchi]

Salut,
Il me semble que GetProcAdress s'utilise avec la signature de la fonction que tu veux r�cup�rer :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
 
typedef int(*t_pfn_proc)() 
t_pfn_proc osal_dynlib_getproc(m64p_dynlib_handle LibHandle, const char *pccProcedureName)
{
    if (pccProcedureName == NULL)
        return NULL;
 
    return (t_pfn_proc)GetProcAddress(LibHandle, pccProcedureName);
}

Ou id�alement avec une version g�n�rique (et des std::string � la place de ces affreux char*) :

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
template<class T>
void osal_dynlib_getproc(m64p_dynlib_handle LibHandle, std::string const &name_, T&pf_)
{
    pf_ =(T)GetProcAddress(LibHandle, name_.c_str());
}
 
int main()
{
    int (*pf)();
    osal_dynlib_getproc(0,0,pf);
    if(pf){
    pf();
    }
    return 0;
}

J'avoue que le retour en void* me fait un peu tiquer.

[Narann]

Ok, merci, je vais regarder �a!

J'avoue que le retour en void* me fait un peu tiquer.

Bon, en fait, c'est du multiplateforme.
Le type est d�fini dans un header du projet (apr�s, peut �tre que le m64p_types.h n'est pas bon... Mais le projet fonctionne):

Code :

S�lectionner tout - Visualiser dans une fen�tre � part

1
2
3
4
#ifdef WIN32
#define HINSTANCE* m64p_dynlib_handle;
#ifdef UNIX
#define void* m64p_dynlib_handle;

(dsl je suis au taf, je ne me rappel plus de la syntax exact).
Donc sous Windows, le pointeur est suppos� �tre de type HINSTANCE. Je vais tenter �a aussi...