Exporter des classes non gérées à partir d'une DLL Visual C ++?

Question

Lors de la création d'une DLL avec Visual C ++ 2008, j'ai plusieurs choix. Je peux créer une "Bibliothèque de classes" , ce qui, à mon sens, me donnera une bibliothèque .Net qui utilise l'extension CMI (gérée) du C ++.

Comme je ne le souhaite pas et que je suppose qu'un fichier .LIB statique doit être lié à un autre projet exécutable de fenêtres Visual C ++, j'ai choisi l'option "Projet Win32". et, dans le panneau Paramètres d’application, spécifiez une DLL C ++ (pas de MFC).

Ceci créera un projet avec un fichier .cpp censé se trouver à l'endroit où je définis "les fonctions exportées pour l'application DLL" .

.

Cela ne semble pas être ce que je veux non plus. En gros, ce que je recherche, c’est l’équivalent C ++ natif de ce qui, en C # .NET, serait un assemblage de bibliothèque de classes. Je souhaite regrouper certaines classes dans une DLL, puis demander à un projet .EXE d'utiliser les classes de la DLL en incluant les fichiers d'en-tête du projet DLL et de le lier à un .LIB pour résoudre les références.

Quelle est la manière habituelle de faire cela?

Answer 1

Vous le faites bien. Vous devez marquer vos classes avec __declspec (dllexport) les rendre disponibles en dehors du projet. Lorsque vous construisez le projet, vous allez générer à la fois un fichier .DLL et un fichier .LIB.

Answer 2

• Créer un nouveau projet
• Projet Visual C ++: Win32: Win32
• Paramètres de l'application, sélectionnez DLL et cochez la case "Exporter les symboles".

Lorsque vous générez le projet, une classe exportée est annulée, généralement appelée C {MyLib}.

Answer 3

Vous avez raison de créer une DLL C ++ (pas de MFC). Vous pouvez créer vos classes et les points d'entrée que vous définissez seront exportés à partir de cette DLL pour être utilisés par un autre code C ++ (par exemple, une application Win32 écrite en C ++).

Les noms C ++ étant automatiquement modifiés par le compilateur en valeurs étranges et merveilleuses, il n'est pas pratique de les exporter tels quels si les clients de la DLL sont, par exemple, des programmes C. Mais si tout est en C ++, ça devrait aller.

Si vous créez des classes, vous pouvez choisir de les lier de manière dynamique (en tant que DLL), mais vous aurez besoin d'une bibliothèque d'importation (créée automatiquement pour vous) contenant les définitions de symboles de la DLL. Vous pouvez également choisir de lier statiquement votre code à partir d'une application. Dans ce cas, vous vous retrouveriez avec une bibliothèque statique (également un fichier .LIB) contenant le code de l'objet réel dans vos classes plutôt que des symboles dans une DLL.

L'avantage d'une DLL est bien entendu que si vous écrivez plusieurs applications à l'aide de votre bibliothèque, elles peuvent toutes partager la DLL. avec une bibliothèque statique, ils contiendraient chacun une copie de votre code de bibliothèque.

Answer 4

Je pense que cet article décrit ce que vous essayez de faire: http://www.codeproject.com/KB/mcpp/usingcppdll.aspx

Personnellement, je préfère également exporter les fonctions C (par opposition à C ++) où je rend le pointeur this explicite pour éviter de se soucier de la décoration du nom de la méthode propre au compilateur et de l’exposition des fonctions générées par le compilateur.