6
votes

Créer un non-possédant Shared_PTR?

Je suis assez nouveau à C ++ 11 et je travaille maintenant sur l'amélioration de mes compétences en C ++ en essayant d'éviter une utilisation directe des pointeurs. J'essaie d'écrire un gestionnaire de sprite qui garde une trace des sprites auparavant chargé et libère ceux non utilisés. J'essaie d'utiliser Shared_PTR (pointeur au bitmap) pour cela, mais le gestionnaire doit également conserver un Shared_ptr de créer les sprites avec - de sorte que le nombre de références ne tombe pas à 0. Puis-je déclarer en quelque sorte le "parent" partagé_ptr Dans mon gestionnaire, il ne compte donc pas comme une référence (et crée toujours des copies de possession de ce partage_ptr)?


0 commentaires

3 Réponses :


11
votes

Utilisez un faim_ptr . Cela va résoudre ton problème. Vous n'aurez pas besoin de les libérer car ils seront automatiquement libérés. Utilisez un verrou sur la faiblesse_ptr pour obtenir un partage_ptr.

L'utilisation_count vous donnera également le nombre actuel de références.


2 commentaires

Mon manager tiendrait donc une faiblesse_ptr créée lors de la création du premier Shared_ptr, puis de créer plus de Shared_ptrs de cette faiblesse_ptr? Ça a l'air bien.


Oui. C'est correct. Toutefois, si le premier Shared_ptr sort de la portée, vous devez le recréer.



3
votes

Shared_PTR code> est conçu pour posséder. Si vous souhaitez un pointeur non propriétaire à une partie de votre pragramme, utilisez faible_ptr code> comme:

std::shared_ptr<Object> sp(new Object);
std::weak_ptr<Object>(sp);


0 commentaires

1
votes

Vous essayez de faire une sorte de style de gestion de la mémoire "BackSeat Driver"; Vous souhaitez utiliser partagé-ptr , mais vous souhaitez également contrôler quand partagé_ptr libère des ressources!

Il y a quelques choses évidentes que vous pourriez faire ici.

  1. Il suffit d'utiliser partagé_ptr et ne vous embêtez pas avec aucune sorte de gestion de la mémoire ou de propriété des ressources dans votre classe Sprite Manager. Trust partagé_ptr pour faire son travail. Si vous devez savoir quand une ressource est détruite, vous pouvez toujours utiliser le motif d'observateur ou similaire et avoir votre message de classe de ressources le gestionnaire lorsqu'il est détruit. Bien sûr, cela signifie que vous ne pouvez pas demander à votre responsable Sprite de fournir des références supplémentaires à un sprite existant, ce qui n'est pas si génial.

  2. Écrivez votre propre pointeur intelligent. Ce n'est pas nécessairement trivial, mais écrit un pointeur intelligent à compter de manière spécifique à la ressource n'est pas une science de la roquette (c'est un enfer de beaucoup plus simple que d'écrire quelque chose comme Shared_ptr , par exemple). Le gestionnaire peut ensuite mettre fin à des ressources lorsqu'il y a une seule référence à leur restante (par exemple, sa propre référence).

  3. Tout le monde a déjà mentionné faible_ptr . A tous les avantages de (1) seulement, vous ne pouvez créer que des instances supplémentaires partagée_ptr référençant la même ressource sous-jacente.

    Vous voudrez peut-être également envisager des modèles d'utilisation des ressources et le coût des ressources de chargement. Vous ne voudrez peut-être pas nécessairement détruire une ressource dès que votre demande cesse de le référencer; S'il est à nouveau demandé une seconde plus tard, cela pourrait prendre un certain temps pour le recharger. Libérant paresseusement des ressources lorsqu'ils sont allés inutilisés pendant un peu de temps pourraient être une meilleure approche. Juste une pensée.


1 commentaires

Merci pour le conseil. J'écris un jeu qui est organisé en niveaux - l'idée est de charger le niveau suivant, puis de détruire la précédente sprites partagés sont conservés en vie. Je ne suis pas encore sûr si je vais permettre la charge de ressources dans un seul niveau, mais même si je le fais, cela sera un événement plutôt rare.