Pointeurs de fonction pour winapi fonctions (stdcall/cdecl)
Svp quelqu'un pourrait me donner quelques conseils pour la création de pointeurs de fonction pour MS winapi fonctions? Je suis en train de créer un pointeur pour DefWindowProc (DefWindowProcA/DefWindowProcW) mais obtenir cette erreur:
LRESULT (*dwp)(HWND, UINT, WPARAM, LPARAM) = &DefWindowProc;
error C2440: 'initializing' : cannot convert from
'LRESULT (__stdcall *)(HWND,UINT,WPARAM,LPARAM)'
to 'LRESULT (__cdecl *)(HWND,UINT,WPARAM,LPARAM)'
Je ne peux pas comprendre ce que j'ai besoin de l'utiliser parce que je ne suis pas habitué à la MS ascii/large macros. Par ailleurs, je fais de la création d'un pointeur de fonction pour faire un rapide hack, et, malheureusement, je n'ai pas le temps d'expliquer pourquoi - mais peu importe, je pense que cette question sera utile aux personnes qui ont besoin de créer winapi des pointeurs de fonction.
Mise à jour:
Ce code fonctionne, mais je suis inquiet que c'est une mauvaise pratique (et n'est pas conforme à unicode/ascii options de compilation). Dois-je définir deux spécifications?
LRESULT (__stdcall* dwp)(HWND, UINT, WPARAM, LPARAM) = &DefWindowProc;
Mise à jour 2:
C'est plus agréable (grâce à nobugz):
WNDPROC dwp = DefWindowProc;
Je ne pense pas qu'il soit mauvais de la pratique sur le fait que vos conventions d'appel de match.
cependant, il est fou de MS pour avoir 3 différentes conventions d'appel, ils doivent avoir sélectionné un seul et coincé avec elle!
La sp n'est pas responsable de l' __cdecl et à peine pour __fastcall. Code 64 bits n'a qu'une convention d'appel. Qui ajoute un autre sera tourné.
Nobugz, Microsoft a également thiscall, qui est la valeur par défaut de méthode. Il n'est pas compatible avec n'importe quel de cdecl, stdcall, ou thiscall. Et Microsoft de thiscall n'est pas la même chose que de Borland.
OriginalL'auteur Nick Bolton | 2009-12-28
Vous devez vous connecter pour publier un commentaire.
Corriger la convention d'appel d'incompatibilité comme ceci:
Un typedef peut le rendre plus lisible:
Mais,
<windows.h>
a déjà un typedef pour ce faire, vous pouvez aussi bien l'utiliser:WNDPROC dwp = DefWindowProc;
Probablement préférable d'utiliser "RAPPEL" plutôt que "__stdcall", le cas d'un besoin d'écrire les types par la main, car c'est ce que les en-têtes d'utilisation...
OriginalL'auteur Hans Passant
Vous manque
__stdcall
dans votre prototype. Vous avez besoin d'avoir un correspondant convention d'appel en dehors d'une correspondance de prototype. WINAPI fonctions sont toutes__stdcall
, tandis que la valeur par défaut pour le C++ est__cdecl
.À l'aide de
extern "C" { code }
est une alternative viable.Vous avez raison, Deus Ex Machina. Convention d'appel n'a rien à voir avec de liaison, qui est ce "extern C" contrôles. "Extern C" touche name mangling, et ainsi de la convention d'appel, mais nous ne sommes pas intéressés par amputation des noms ici, étant donné que ni DefWindowProc ni dwp est exporté ou importé dans tout le code qui s'affiche.
Ce qui est pire, c'est que stdcall et cdecl sont suffisamment compatibles que si vous utilisez extern "C" sans correspondance des conventions, le programme de liaison, et l'appel fonctionne parfaitement-mais au retour de l'appel, vous avez endommagé les variables locales (et si l'appel était la dernière chose dans la méthode, vous ne remarquerez même pas, depuis le retour sera généralement de fonctionner correctement). Un grand piège de l'attente pour les imprudents. (Et oui, j'ai eu de déboguer le code atteints de ce problème).
Aussi, si vous laissez le compilateur d'optimiser loin de la pile standard de cadrage code, le retour peut faire planter votre application. On peut se demander si c'est mieux ou pire, au moins, c'est plus facile à trouver. 🙂
OriginalL'auteur Kornel Kisielewicz
Ce n'est pas la "folie" MS ascii/à l'échelle macro, vous avez juste 2 les différentes déclarations de fonction.
Si vous décorez votre intérieur de la fonction avec "extern C" autour de lui, vous allez exposer votre fonction avec le même type d'appel que l'original et il va compiler.
OriginalL'auteur gbjbaanb