J'essaie simplement de mieux comprendre les fonctions externe C.
Selon mes connaissances, une fonction externe C est toujours une fonction que vous essayez d'appeler à partir d'une application déjà compilée. Soit une bibliothèque exécutable, statique ou dynamique. donc ma question est ... est ma compréhension correcte ?? Doit-il toujours être un pointeur de fonction C ?? ' Pourquoi devez-vous utiliser un TypeDEF pour chaque fonction ?? Je présume que lorsque vous utilisez le getProcAddress (). Vous allouez la mémoire sur ce document des applications particulières et non celle que vous l'appelez. Par conséquent, vous devez le relâcher de ce tas aussi bien ??
5 Réponses :
Il n'est pas nécessaire d'être un pointeur de fonction. Vous pouvez spécifier la déclaration de fonction normalement et le préfixer avec Si vous utilisez même lorsque vous utilisez des pointeurs de fonction (tels que Ceux qui sont retournés par getProcaddress), vous ne avez pas utiliser extern "c" , comme indiqué dans Certains exemples Microsoft . getProcAddress () Vous n'allumez aucune mémoire. Vous obtenez simplement l'adresse de la mémoire de la fonction à l'intérieur de la DLL déjà chargée dans la mémoire (avec LoadLibrary () , probablement). Typef , c'est juste que le code a l'air assez moche sans elle. Il est toujours difficile de comprendre quoi écrire aussi. Je pense que ce serait quelque chose comme:
Notez que __cdecl est spécifique à Microsoft.
@Billy Oneal: SO est getprocAddress et Visual Studio.
GetProcAddress n'est pas spécifique à Microsoft, mais il est spécifique Windows. Je peux utiliser GetProcaddress avec Mingw par exemple, mais pas __cdecl.
Et pour l'enregistrement I + 1'd, je pensais juste que c'était une note importante.
externe "c" {} est une convention C ++ pour déclarer que les fonctions ci-jointes sont des fonctions C - et non des fonctions C ++. C ++ a une convention de dénomination légèrement différente qui est conflictuelle avec C. Si vous avez une bibliothèque écrite en C et que vous souhaitez l'utiliser dans un programme C ++, vous devez utiliser extern "C" {} pour que le compilateur sait que celles-ci sont des fonctions C. Si la bibliothèque a été écrite en C ++, je pense que l'extern "c" {} provoquera une erreur.
Notez que l'extérieur a plusieurs significations - ce cas spécifique est une convention C ++ et n'est pas liée à des utilisations différentes de l'extérieur. Par exemple, a une signification complètement différente que celle externe "c" {}. Le typeEf est séparé de l'extérieur "C" {} publier. TLECDEFS vous permet de créer des alias pour des types courants qui ont plus de sens. Par exemple, déclarer des structures est souvent un processus verbeux. Je peux utiliser un typlef pour raccourcir: Ainsi, dans votre exemple, le HRESULT est vraiment un alias pour (* crééevice) () Bien que je pense que vous devez le mettre avant la fonction (et pas après).
extern "c" a 2 implications. Premièrement, il déclare que les noms symboliques des fonctions ne sont pas "Nom gigamment" pour prendre en charge C ++. Deuxièmement, il indique au compilateur que la fonction est appelée à l'aide de la Convention C appelant C plutôt que la Convention téléphonique Pascal. La différence concerne lorsque l'adresse de retour est poussée sur la pile. L'utilisation de la mauvaise convention appelante plantera votre application.
Cette déclaration est destinée au compilateur et non à la liaison. La fonction externe C pourrait donc exister dans vos propres modules ou dans une bibliothèque binaire: la source d'octets réels pour la mise en œuvre de la fonction est résolue par la liaison. Si la signature de fonction est déclarée une fonction C ++ régulière et non externe C, le compilateur manglera le nom symbolique pour coder les informations de type de la signature de fonction. Cela le rendra incompatible avec le code d'objet généré par d'autres compilateurs C ++. Par conséquent, la création d'une fonction externe C vous permet de partager le code entre compilateurs sous forme binaire. Notez que vous ne pouvez pas exposer les fonctions des membres de cette façon, seules des fonctions C de style ancien.
Un aspect important de la spécification Pour que les fonctions de votre bibliothèque puissent être chargées à l'aide de extern "C" La liaison est que les noms de fonction ne sont pas mangés, ce qui est la valeur par défaut pour les noms C ++.
getProcAdress , vous devez soit ajouter la fonction au . DLOF , utilisez __ DeclSpec (dllexport) ou utilisez extern "C" .
Pour répondre, dans l'ordre:
Les fonctions externes "c" sont utilisées pour Interop avec C de C ++. L'utilisation d'eux a la conséquence que C code C peut appeler la fonction. Comme l'API Windows est une API de Windows, toutes les fonctions sont externes "C" pour s'assurer que C et C ++ Code peut utiliser l'API.
Pour que les programmes C ++ soient interagir avec d'autres langues, y compris C, en tant que convention, les fonctions sont exportées à l'aide d'externe "C". C'est pourquoi beaucoup de code DLL fait cela. Ce n'est pas une exigence technique cependant.
donc non, il n'est pas nécessaire d'être un pointeur de fonction C.
Le code exemple fourni est à partir d'un fichier d'en-tête qui publie les exportations d'une DLL deux fois - une fois l'ensemble des méthodes externes "C" exportées de manière à ce que la DLL puisse être liée statiquement. L'autre en tant qu'ensemble de types de pointeur de fonction, de sorte que la DLL puisse être chargée de manière dynamique et les types de pointeur de fonction utilisées avec GetProcAddress.
Avez-vous vu cette question? Stackoverflow.com/questions/67894/...