Est-il acceptable d'utiliser boost :: ptr partagé dans l'interface DLL?

Question

Est-il valide pour développer une DLL en C ++ qui retourne boost a partagé les pointeurs et les utilise comme paramètres?

Alors, est-il autorisé à exporter des fonctions comme ça?

1.) boost::shared_ptr<Connection> startConnection();
2.) void sendToConnection(boost::shared_ptr<Connection> conn, byte* data, int len);

En particulier: Est-ce que le travail de comptage de référence à travers les frontières de DLL ou serait l'exigence est que EXE et DLL utilisent le même moteur d'exécution

L'intention est de surmonter les problèmes de propriété de l'objet. Ainsi, l'objet est supprimé lorsque les deux dll et exe ne référencent pas plus.

Answer 1

Selon Scott Meyers en C ++ efficace (3e édition), shared_ptrs sont en sécurité à travers les frontières dll. L'objet shared_ptr garde un pointeur vers la destructor du dll qui l'a créé.

  

Dans son livre au point 18, il déclare: « Une caractéristique particulièrement agréable de   TR1 :: shared_ptr est qu'il utilise automatiquement son Deleter par pointeur   pour éliminer une autre erreur de client potentiel, le « problème inter-DLL. »   Ce problème affleure lorsqu'un objet est créé en utilisant un nouveau dans   dynamiquement bibliothèque liée (DLL) est supprimé, mais dans une DLL différente. Sur   de nombreuses plates-formes, telles paires nouvelles / supprimer cross-DLL mènent à la durée d'exécution   les erreurs. TR1 :: shared_ptr éviter le problème, car sa valeur par défaut Deleter   utilise supprimer de la même DLL où le TR1 :: shared_ptr est créé. "

Tim Lesher a une Gotcha intéressante à surveiller, cependant, qu'il mentionne ici . Vous devez vous assurer que la DLL qui a créé le shared_ptr n'est pas déchargé avant que le shared_ptr va finalement hors de portée. Je dirais que dans la plupart des cas, ce n'est pas quelque chose que vous devez surveiller, mais si vous créez dll qui sera accouplées alors je vous recommande vaguement contre l'utilisation d'un shared_ptr.

Un autre inconvénient potentiel fait que les deux côtés sont créés avec des versions compatibles de la bibliothèque Boost. Le shared_ptr Boost est stable depuis longtemps. Depuis au moins 1,34 il a été TR1 compatible.

Answer 2

À mon avis, si ce n'est pas dans la norme et ce n'est pas un objet / mécanisme fourni par votre bibliothèque, il ne devrait pas faire partie de l'interface à la bibliothèque. Vous pouvez créer votre propre objet pour faire le comptage de référence, et peut-être utiliser l'amplification en dessous, mais il ne devrait pas être exposé explicitement dans l'interface.

Answer 3

DLLs ne ressources normalement pas propres - les ressources sont la propriété des processus qui utilisent la DLL. Vous êtes probablement mieux de retourner un pointeur ordinaire, que vous pouvez ensuite stocker dans un pointeur partagé sur le côté appelant. Mais sans plus d'informations, il est difficile d'être certain à 100% à ce sujet.

Answer 4

Quelque chose à affût si vous exposiez des pointeurs premières à partir d'une interface dll. Il vous oblige à utiliser le CRT dll partagée, la mémoire allouée dans un tube cathodique ne peut pas être désalloué dans un tube cathodique différent. Si vous utilisez le CRT dll partagé dans tous vos modules (de dll & exe), alors vous êtes bien, ils partagent tous le même tas, si vous ne vous traverserez CRT et le monde Meltdown.

En dehors de cette question, je suis d'accord avec la réponse acceptée. L'usine de création ne devrait probablement pas définir la propriété et la gestion du cycle de vie du code client.

Answer 5

Non, ce n'est pas.

La mise en page de boost::shared_ptr<T> pourrait ne pas être le même des deux côtés de la frontière de DLL. (Mise en page est influencée par la version du compilateur, l'emballage pragma, et d'autres options de compilation, ainsi que la version actuelle du code source Boost).

Only "mise en page standard" (un nouveau concept en C ++ 11, en rapport avec les anciens "POD = anciennes données simple" concept) types peut être en toute sécurité passé entre les modules séparément construits.