Windows, Qt, const char* et const WCHAR*

Version imprimable

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:

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:

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:

m64p_dynlib_handle pluginHandle;

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

Code:

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!

02/08/2010, 20h34
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:

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

Code:

return static_cast<void*>(GetProcAddress(private_->pluginHandle, name));//Ou reinterpet cast (je ne sait jamais).
02/08/2010, 20h44
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...:oops:)

Citation:

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.

Citation:

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):

Citation:

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!
02/08/2010, 21h50
Narann

Bon:

Citation:

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

Ne fonctionne pas.

Par contre, avec :

Citation:

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!

:ccool:

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

Code:

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:

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.

06/08/2010, 18h15
Narann
Ok, merci, je vais regarder �a! :)

Citation:

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:

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...
07/08/2010, 07h14
3DArchi
Citation:
Envoy� par Narann

Ok, merci, je vais regarder �a! :)

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:

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...
Je pensais au type retour de ta fonction : void * LibraryLoader::resolve. Pourquoi ne pas retourner directement le pointeur de fonction bien typ� ?
07/08/2010, 12h07
Narann

Citation:

Envoy� par 3DArchi

Pourquoi ne pas retourner directement le pointeur de fonction bien typ� ?

Je suppose que c'est parce que la fonction resolve renvoit des fonctions qui elles m�me renvois diff�rents types de valeur...

Enfin je suppose... :(
09/08/2010, 09h10
3DArchi

Salut,
Justement avec une approche g�n�rique, tu peux avoir un typage fort plus rapidement.
09/08/2010, 20h08
Narann

Merci pour cette r�ponse. :) Je n'ai pas tout compris.
Mais si vous avez le temps (ou un simple lien), je suis preneur.:roll:

Citation:

Envoy� par Narann

Merci pour cette r�ponse. :) Je n'ai pas tout compris.
Mais si vous avez le temps (ou un simple lien), je suis preneur.:roll:

C'�tait l'exemple que je proposais plus haut :
Code:

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; }
La fonction est directement r�cup�r�e avec le bon type.