J'ai une DLL qui doit accéder aux données stockées dans des conteneurs STL dans l'application hôte. Étant donné que C ++ n'a pas de standard abi, et je souhaite prendre en charge différents compilateurs, l'interface entre l'application et la DLL doit fondamentalement rester des données simples.
pour les vecteurs, cela est relativement simple. Vous pouvez simplement retourner le bloc de mémoire du vecteur, car il est garanti d'être contigieux: maintenant la DLL peut avoir un accès en lecture seule en lecture seule aux données du vecteur via cette interface. La DLL peut également envelopper cela pour copier le contenu d'un vecteur pour lui-même. Quoi des listes STL (et DESQUES) cependant? Y a-t-il un autre moyen simple d'autoriser l'accès via une limite DLL? Ou devrai-je recourir à une sorte d'interface GetFirst () / GetNext ()? Je devrais peut-être faire cela pour beaucoup de listes, il serait donc agréable d'avoir une solution aussi simple que celle des vecteurs.
3 Réponses :
l'interface entre l'application et dll doit fondamentalement rester données simples.
Pas nécessairement. Vous devez être sûr que la même version du compilateur est utilisée. En outre, construisez des paramètres qui ont une incidence sur la disposition des objets STL sont exactement les mêmes entre la DLL et l'application.
Si vous deviez libérer la DLL dans la nature, vous avez raison d'être préoccupé par l'exposition des limites de la DLL. Si, toutefois, tout est sous votre contrôle et purement interne (ou si vous pouvez appliquer de manière rigoureuse des paramètres de construction / compilateur de 3ème partie), cela devrait aller.
Vous avez raison que je puisse vous en sortir si tous les paramètres de compilation sont les mêmes. Mais ceci est pour une architecture de plug-in et j'aimerais prendre en charge différents compilateurs. J'ai édité la question de clarifier cela.
Je suis d'accord avec cela, mais vous devriez peut-être insister sur le fait que ce n'est pas seulement la mise en page - le code doit avoir été compilé avec la même version du compilateur, de sorte que les mises en œuvre de méthodes telles que neuves et suppriment correspondent.
Si vous appliquez de manière rigoureuse les paramètres de construction / les versions de compilation et que tout est sous votre contrôle, ce qui est donc l'avantage des DLL par rapport à l'utilisation de bibliothèques statiques et de relier tout ensemble dans un exécutable?
@MARTINB Un avantage est que vous pouvez réutiliser le même module partagé sur plusieurs applications internes. Si une seule application est en cours de développement, il n'y a aucun avantage sur la liaison statique.
Peut-être que vous pouvez passer quelque chose comme des "poignées" pour énumérer / itérateurs deque? Ces types de manipulateurs seraient opaques et déclarés dans un fichier d'en-tête que vous expédieriez aux utilisateurs. En interne, vous auriez besoin de cartographier les valeurs de la poignée pour répertorier / déchets Itérateurs. Fondamentalement, l'utilisateur écrirait du code comme:
Vous pouvez transmettre des objets STL entre les DLL et prendre en charge différents compilateurs si vous faites attention où vous instaniez chaque type stl. Vous avez besoin de macros intelligents "Dllexport" - J'utilise l'ensemble suivant pour prendre en charge avec succès VC et GCC.
extern template class __declspec(dllimport) std::vector<std::string>;
C'est une solution très intéressante - devrais-je faire la même chose pour STD :: Vector
Vous n'avez pas besoin d'instancier les itérateurs car lorsque vous instaniez une classe de conteneurs STL spécifique, vous obtenez également un code pour toutes les classes de la classe de conteneurs. Je ne sais pas de consommer des classes stl d'un hôte EXE - je n'ai pas personnellement essayé que si vous souhaitez suivre cette méthode, vous devrez faire un peu d'expérimentation avec un test simple.
Ici, il est dans msdn: L'article MSDN (question 168958) n'incitte-t-il pas que la liste, la carte et les autres conteneurs ne peuvent être exportés, seul vecteur peut?