J'utilise VS2008 dans Win7 et G ++ 4.7 à Centos 18. Le problème est vu uniquement sur Windows lorsque j'ai utilisé une bibliothèque partagée de manière dynamique. Lorsque je convertit la bibliothèque statique, le programme lie bien.
Je comprends que dans les fonctions de modèle de bibliothèque partagées / la classe, soit définie dans le fichier d'en-tête ou l'instanciation des gabarits des types de modèle (paramètres) doit être fournie via une unité de compilation. J'ai choisi l'option ultérieure. Je l'ai déjà fait auparavant, j'ai traversé
bibliothèque partagée C ++ avec modèles: erreur de symboles non définis mais je ne peux pas comprendre pourquoi sous Windows dès que je convertit la bibliothèque. DLL Il n'a pas réussi à résoudre les symboles:
Erreur LNK2019: Symbole externe non résolu "Void __cdecl AideGistration (Double)" (?? $ AideGistrationGistration @ n @@ Yaxn @ z) Référencé dans la fonction _MAIN dans Windows, il fonctionne bien avec la bibliothèque statique.
Sous Linux, la bibliothèque dynamique et partagée fonctionne. // bibliothèque de la bibliothèque .cpp // symbole windows exportateur // utilisateur de la bibliothèque .cpp
3 Réponses :
Je pense que vous devez exporter les spécialisations. Avez-vous essayé cela dans votre fichier .cpp. CPPP: et à peu près identique dans votre en-tête: i pense qui fonctionnera avec votre macro d'exportation (en supposant que le fichier .CPP Voir J'admets que j'ai dessiné ma réponse de cette autre réponse sur les Intarwebs: http://social.msdn.microsoft.com/forums/vstudio/en-us/4fd49664-E28E- 4F23-B1EB-B669D35AD264 / Modèle de fonction-Modèle-Instantation-export-from-dll (faites défiler tout le chemin vers le bas de la version finale de Franjo555) __ DeclSpec (dllexport) et l'en-tête voit __ DeclSpec (dllimport) ). J'admets que je ne suis pas un expert avec Windows ' __ DeclSpec .
Les symboles de modèle de classe sont présents. Mais les symboles de modèle de fonction gratuits sont manquants. J'ai utilisé Dumbin / Export pour voir les symboles. J'ai élaboré une solution que je vais poster ensuite.
Votre idée a eu raison, même si j'avais besoin d'exporter les instantanations du modèle de fonction ... merci
Vous n'avez pas besoin de __ DeclSpec (Dllimport) Les méthodes, en supposant que la classe elle-même est exportée / importée.
Notez que exporter ici devrait être après classe , pas avant de cela. Si c'est avant cela, aucune exportation n'est générée.
Veuillez noter que la spécialisation exportée de la classe de modèle TE dans le fichier .CPP doit apparaître avant toute méthode spécialisée, pas après. Testé sur VS2017.
J'ai élaboré le problème. Sous Windows Class Model et Modèle de fonction sont exportés différemment et une lecture intéressante sur le net est exportée.
compilateurs VS compilers Symboles de classe de classe Symboles Si le modèle de classe est instancié sur l'unité de traduction (.cpp).
Toutefois, dans le cas de modèle de fonction, le mot-clé '__declSpec (dllexport) doit être Présent explicitement pour que les symboles soient présents sur la bibliothèque dynamique.
par exemple par exemple C'est juste un autre cas où vs décide des choses différemment. Il y a une lecture intéressante ici:
http://www.codesynthesis.com / ~ boris / blog / 2010/01/18 / dll-export-cxx-templats /
Je crois que c'est parce que Compiler crée un code spécialisé pour la classe de modèles lorsque la classe de modèle est utilisée pour la première fois avec un paramètre spécifique. Étant donné que le compilateur utilise uniquement les fichiers d'en-tête fournis (.h) lors de la complication d'une unité de compilation (fichiers .cpp) tout le code TMPLATE doit être disponible dans les fichiers .h. Vous pouvez exporter des classes de modèle spécialisées d'une DLL mais pas les classes de modèle elles-mêmes.
Il y a des milliers de milliers de doublons à celui-ci. Vous ne pouvez pas diviser les classes modèles en en-tête et à un fichier source comme d'habitude, tout doit être dans les en-têtes.
Dupliqué possible de Pourquoi les modèles peuvent-ils seulement être implémentés dans l'en-tête Fichier?
@ Joachim Pileborg Il peut certainement être fait comme indiqué dans la réponse fournit dans la question Stackoverflow.com/questions/495021/... et je le fais aussi uniquement dans Windows DLL IT CAUSANT LA QUESTION DE LA QUESTION PLEINE première
@juanchopanza Le lien que vous avez fourni n'explique pas pourquoi seulement sur la DLL partagée, cela provoque un problème
Cela n'explique pas pourquoi il "seulement" provoque des problèmes dans une DLL, mais il explique pourquoi Cela cause ces problèmes. Vous devriez demander pourquoi quelque chose brisé semble fonctionner dans une bibliothèque statique. En fait, vous ne devriez pas essayer d'utiliser le code brisé.
@ Juanchopanza J'ai parcouru les liens que vous avez fournis et suggère si une instanciation explicite est fournie, elle devrait fonctionner et elle fait avec g ++ compiler. C'est bon si vous ne connaissez pas la réponse spécifique VS2008, mais pourquoi les autres peuvent connaître la réponse.