Bienvenue, Invité. Merci de vous connecter ou de vous inscrire.
Avez-vous perdu votre e-mail d'activation ?

Auteur Sujet: Gestion Mémoire et RAII  (Lu 878 fois)

0 Membres et 1 Invité sur ce sujet

TheNawaKer

  • Newbie
  • *
  • Messages: 2
    • Voir le profil
    • Millenium Portail Jeux Indé
Gestion Mémoire et RAII
« le: Février 09, 2015, 06:34:45 am »
Bonjour, je suis actuellement en train de développer une application dans le cadre de mes études et je souhaiterais gérer proprement la mémoire.
Ayant déjà réalisé auparavant un système de caching de ressource, je suis en train de légèrement l'adapter pour SFML. En effet, principalement composé d'une map contenant des weak_ptr comme valeurs, ceux-si sont créer lors de l'ajout d'une ressource. La fonction qui ajoute ma ressource ainsi que le getter me renvoi un shared_ptr afin de maintenir en memoire la ressource contenu dans le cache tant que celle-ci est utiliser par un shared_ptr. Lorsque plus aucun shared_ptr ne l'utilise, celle-ci est détruite.

Mon problème est le suivant:
Imaginons que je stocke les différentes textures/images que j'utilise, jusque la tout va bien.Là où cela commence à ce gâter est lorsque je veux utiliser ces ressources. En effet, par exemple, si je veux utiliser une texture et l'associé à un sprite, le shared_ptr ne sera pas utilisé car sprite prend en paramètre une texture par reference et donc lorsque je quitterai ma fonction, celui-ci sera détruit et du même temps provoquera la destruction de la ressource du cache.

Du code étant peut être un peu plus parlant ,en voici:
Class Bouton{
Private:
     sf::Sprite sprite;
Public:
     Bouton(std::string file){
          Cache<Texture> ct; //le cache contient des attributs static
          std::shared_ptr<Texture> s=ct.get(file);//je récupéré la texture
          sprite.setTexture(s.get())//je définie la texture utilise par le sprite
}//fin de la fonction -> le shared_ptr est détruit, le compteur étant à 0 -> destruction de la ressource contenu dans le cache
//(le pointeur dans sprite ne comptant pas car c'est un pointeur classique)
};
 

Si vous avez des idées, je suis preneur :)
(P.S: l'intérêt du cache est de détruire la ressource lorsque celle-ci n'est plus utilisé. Une map d'unique_ptr (à la place de weak_ptr) n'est donc pas vraiment une bonne solution :S )
« Modifié: Février 09, 2015, 06:41:52 am par TheNawaKer »
Rédacteur Millenium et étudiant en licence 3 d'ingénierie informatique

Laurent

  • Administrator
  • Hero Member
  • *****
  • Messages: 32504
    • Voir le profil
    • SFML's website
    • E-mail
Re : Gestion Mémoire et RAII
« Réponse #1 le: Février 09, 2015, 07:45:37 am »
La solution évidente est de garder une instance de ton shared_ptr<Texture> dans la classe Button.

Une autre solution est de garder des shared_ptr et non des weak_ptr dans le cache. Les ressources ne seront ainsi plus détruites automatiquement, c'est plutôt toi qui va choisir le moment de leur destruction explicitement. C'est un autre choix de conception.

Et au fait :
Citer
Cache<Texture> ct; //le cache contient des attributs static
          std::shared_ptr<Texture> s=ct.get(file);//je récupéré la texture
C'est bizarre d'instancier une classe pour uniquement utiliser ses membres statiques. Pourquoi pas :
          std::shared_ptr<Texture> s=Cache<Texture>::get(file);
Laurent Gomila - SFML developer

TheNawaKer

  • Newbie
  • *
  • Messages: 2
    • Voir le profil
    • Millenium Portail Jeux Indé
Re : Gestion Mémoire et RAII
« Réponse #2 le: Février 09, 2015, 09:40:15 am »
Tout d'abord merci de ta réponse.
1) oui effectivement une idée tellement simple qu'elle ne m'a même pas traversé l'esprit. Une autre idée est de créer une classe abstraite contenant un shared_ptr comme membre et de créer une nouvelle classe héritant de sprite et de ma classe abstraite. Ainsi, la gestion mémoire resterait invisible ^^

2)j'ai déjà pensé à cette idée, mais l'inconvénient, c'est que ma suppression ne se fait pas automatiquement. Après, cela peut être utile dans certain cas. Ma seule remarque par contre, c'est qu'au lieu d'utiliser un shared_ptr qui fait deux allocations (l'objet + le compteur d'utilisation), autant utiliser un unique_ptr qui n'en fait qu'une seule.

3) Bien vu pour mon utilisation bizarre de ma classe. J'ai juste pas fait attention a ce que j'écrivais dans le code (je voulais insisté sur le fonctionnement de mon cache avec le commentaire)
Pour ma défendre je dirais qu'il était tard xD
Rédacteur Millenium et étudiant en licence 3 d'ingénierie informatique

 

anything