Il est courant de déclarer des objets contenus comme des pointeurs de cette classe, tandis que "avancement de la déclaration" dans le fichier d'en-tête. Ceci afin de réduire les dépendances physiques dans le code.
par exemple serait-il une bonne idée de déclarer un tel membre comme partagé_ptr, au lieu d'un pointeur nue? Je préférerais Scoped_ptr, mais AFaik, cela ne sera pas en standard.
4 Réponses :
Dans le cas d'une composition, oui c'est une bonne idée si vous ne voulez pas dépendre de la dépendance physique. Ensuite, votre B sera détruit automatiquement quand A est.
Si cela ne vous dérange pas de dépendance physique, vous pouvez simplement tenir l'élément de données par la valeur.
(vous pouvez également vérifier l'idiome PIMPL si la dépendance physique est un problème.)
Oui, vous pouvez (devrait?).
Ceci est un pratique courante . Comme vous l'avez dit, cela évite la nécessité d'appeler explicitement supprimer (). Vous pouvez aller encore plus loin. Voici un exemple: que je initialise comme ceci: Quand D_RSA ne sera plus utilisé, un Appel automatique à si Cela dépend de la manière dont vous voulez que votre classe entourant se comporte en ce qui concerne la copie. rsa_free () se produira. N'est-ce pas cool ?!
Mise à jour
C ++ 11 est une option, vous devez probablement mieux utiliser std :: unique_ptr à la place qui a moins de frais généraux et est mobile.
La distribution automatique des membres est exactement ma question :)
Si ce pointeur n'est pas transmis de votre classement et la vitesse d'exécution est cruciale, utilisez Scoped_PTR au lieu de Shared_Ptr. Shared_Ptr a une surcharge.
Je crois que Scoped_PTR n'est pas dans la norme Incomming C ++ 0X.
@idimba, unique_ptr est la version C ++ de celui-ci, qui est également mobile.
Utilisation d'un Le seul avantage qu'un pointeur intelligent aura, c'est que vous n'aurez pas besoin de rappeler de mettre un Lorsque vous n'avez pas besoin de vous inquiéter des problèmes de propriété, même un Shared_PTR vous permettrait de passer de la propriété à un autre objet, de sorte qu'il ne soit pas détruit lorsque votre objet extérieur est détruit. Vous déclarez que cela ne serait pas une préoccupation dans ce cas particulier.
Supprimer PB dans votre destructeur. Cela peut être suffisant pour la plupart des gens.
auto_ptr sera assez bon.
Si vous avez besoin de Sémantics du pointeur partagé - pourquoi pas? Je ne suis pas clair ce que vous demandez réellement ici.
Je n'ai pas besoin de pointeur partagé sémantique. Depuis que je déclare que B soit un pointeur sur B (pour réduire les dépendances phaistiques des classes de classe A), je dois créer B en appelant nouveau. Par conséquent, j'ai besoin de le supprimer dans le D-tor. Ce n'est pas beaucoup de travail, mais la question si vous utilisez Shared_PTR ici, pour prendre soin de B de contrat de vente, est une bonne proctice ou non.
@idimba: Si vous n'avez pas besoin de ce qu'est un pointeur partagé, pourquoi utiliseriez-vous un? Si vous n'avez pas besoin de ce qu'un pointeur a à offrir, n'utilisez pas une de ces non plus. Une très bonne règle de base est de ne pas utiliser une fonctionnalité de langue qui ne correspond pas à ce que vous essayez de faire.
partagé_ptr / unique_ptr ftw! !
Pourquoi cela peut réduire les dépendances physiques dans le code.