Y a-t-il un meilleur moyen de charger une DLL en C ++?

Vous pouvez créer un lien vers les symboles de la DLL directement au lieu d'utiliser getProcAdress () code>, qui obtient l'adresse d'une fonction au moment de l'exécution.

exemple de fichier d'en-tête SNIPPET: P>

#if defined(MY_LIB_STATIC)
#define MY_LIB_EXPORT
#elif defined(MY_LIB_EXPORTS)
#define MY_LIB_EXPORT __declspec(dllexport)
#else
#define MY_LIB_EXPORT __declspec(dllimport)
#endif

#ifdef __cplusplus
extern "C"
{
#endif

int MY_LIB_EXPORT Factorial(int n);

#ifdef __cplusplus
}
#endif

Dans le monde Windows, il y a (au moins) 4 façons d'utiliser des DLL:

1. Dynamique d'exécution Dynamique Linking (quoi Vous faites maintenant)
2. lien dynamique de chargement (le "type typique" d'utiliser des dlls)
3. Lien dynamique de chargement retardé
4. DLL Transfert

   Je n'ai pas à expliquer Dynamique d'exécution LIENNEZ Puisque vous le faites déjà. Je choisis de ne pas expliquer la liaison dynamique de délai de chargement de retard au-delà de décrire simplement ce qu'il est en termes généraux. La charge de retard est essentiellement identique à la liaison dynamique de charge de charge, sauf qu'il est fait juste dans le temps au lieu de la charge de l'application. Ce n'est pas aussi utile ni aussi bénéfique que vous pourriez penser, il est difficile de travailler avec et de manière difficile à coder. Alors n'allons pas là, au moins pour le moment. le transfert de DLL est encore plus exotique que le chargement de retard - si exotique, je n'en ai même jamais entendu parler jusqu'à @MOX l'a mentionné dans les commentaires. Je vous laisserai lire le lien ci-dessus pour en apprendre, mais il suffit de dire que le transfert de la DLL est lorsque vous appelez une fonction exportée dans une DLL, mais cette demande est en réalité transmise à une autre fonction dans un DLL différente.

   Liaison dynamique de chargement de temps

   C'est ce que je considérerais comme la Vanilla DLL relie .

   C'est ce que la plupart des gens se réfèrent lorsqu'ils se réfèrent à l'utilisation de DLL dans leurs applications. Vous venez de #include le fichier d'en-tête de la DLL et lien vers le fichier LIB. Pas besoin de getProcAddress () ou créer un pointeur de fonction Typefs. Voici comment cela fonctionne en un mot:

   1) Vous obtenez généralement 3 fichiers: une DLL avec le code d'exécution, un fichier LIB et un fichier d'en-tête. Le fichier d'en-tête est juste un fichier d'en-tête - il décrit toutes les installations de la DLL que vous pouvez utiliser.

   2) Vous écrivez votre application, #include 'ing dans le fichier d'en-tête de la DLL et effectuez des appels sur ces fonctions, comme vous pouvez utiliser n'importe quelle fonction dans n'importe quel fichier d'en-tête. Le compilateur connaît les noms des fonctions et des objets que vous utilisez car ils sont dans le fichier d'en-tête de la DLL. Mais cela ne sait pas où ils sont encore en mémoire. C'est là que le fichier lib est ...

   3) Vous allez sur les paramètres de la liaison pour votre projet et ajoutez une "dépendance supplémentaire de la bibliothèque", spécifiant le fichier LIB. Le fichier LIB indique à la liaison où les fonctions et les objets que vous utilisez à partir du fichier h résident dans la mémoire (en termes relatifs, non absolus, évidemment).

   4) Compilez votre application. Si vous avez tout configuré correctement, cela devrait compiler, relier et exécuter. Lorsque vous obtenez des erreurs de liaison "non résolues de référence externe", cela est généralement dû à des choses qui ne sont pas configurées correctement. Vous ne pouvez pas non plus spécifier le chemin correct vers le fichier LIB ou vous devez inclure plus de fichiers lib.