Discussion :

[Christophe]

Bonjour,

J'ai un icône dans un QPushButton, crée depuis un fichier png inclus dans les QRessources.

de cet icône je récupère l'image dans un QImage, je modifie ensuite le QImage ( rempl de couleur ).

Je crée un nouveau QIcon acec ce QImage et refait un setIcon.

Pour éviter une fuite mémoire, je pense que je dois faire un delete sur mon ancien icône, qu'en pensez-vous ? Par ailleurs, le contenu de la ressource reste en mémoire je pense, donc il me restera en mémoire au moins la version des ressources. ( c'est un tout petit fichier - donc pas très grave, c'est juste par curiosité )

Par ailleurs ceci m'amène une nouvelle question : comment fonctionne les ressources ? chargement en mémoire lors du chargement du fichier ? ou lors d'un 1er accès ? est-ce pareil sur windows, linux, et mac os x ? - cette question sors un peu du cadre de Qt mais bon.

[koala01]

Bonjour,

J'ai un icône dans un QPushButton, crée depuis un fichier png inclus dans les QRessources.

de cet icône je récupère l'image dans un QImage, je modifie ensuite le QImage ( rempl de couleur ).

Je crée un nouveau QIcon acec ce QImage et refait un setIcon.

Pour éviter une fuite mémoire, je pense que je dois faire un delete sur mon ancien icône, qu'en pensez-vous ?

Je ne pense pas.

Le principe de Qt est toujours de rendre le widget parent des éléments qu'on lui donne.

Chaque fois que tu utilises une fonction setXXX ou addYYY qui prend un pointeur comme argument, l'élément au départ duquel tu invoques la fonction va automatiquement prendre la responsabilité de détruire l'objet pointé par le pointeur ( comprends : invoquer delete sur le pointeur au moment opportun).

Il en va normalement de même lorsque tu invoque setIcon sur un bouton (ou n'importe quel widget)

Au contraire, invoquer toi-même delete sur le pointeur vers ton icone a de très fortes chances de provoquer ce que l'on appelle une double tentative de libération de la mémoire :

En invoquant delete sur ton pointeur, tu libères explicitement la mémoire allouée à ton icone, mais, en invoquant setIcon au départ de ton bouton, cela a pour résultat d'invoquer delete sur le pointeur vers l'icone qui est initialement utilisée par le bouton.

Or, ce pointeur n'est rien d'autre que ... le pointeur sur lequel tu as déjà invoqué delete

Le deuxième delete (celui qui sera effectué lors du setIcon) va essayer de libérer un espace mémoire qui a déjà été libéré on est en présence de ce que l'on appelle un comportement indéfini qui, dans le cas présent, résultera plus que vraisemblablement en une erreur de segmentation.

Par ailleurs, le contenu de la ressource reste en mémoire je pense, donc il me restera en mémoire au moins la version des ressources. ( c'est un tout petit fichier - donc pas très grave, c'est juste par curiosité )

Par ailleurs ceci m'amène une nouvelle question : comment fonctionne les ressources ? chargement en mémoire lors du chargement du fichier ? ou lors d'un 1er accès ? est-ce pareil sur windows, linux, et mac os x ? - cette question sors un peu du cadre de Qt mais bon.

Je ne me suis jamais vraiment intéressé à la mécanique interne des fichiers de ressources.

Mais, ce que je sais, c'est qu'ils ont pour résultat d'ajouter le contenu des fichiers indiqués directement au niveau du binaire de l'exécutable.

On assiste peut être à un phénomène de compression à cette occasion (qui occasionne peut être une décompression quand le contenu du fichier indiqué comme ressource est utilisé)... ou non.

Par contre, ce qui est sur, c'est que, si tu déclares une variable qui va spécifiquement charger le contenu du fichier fourni comme ressource (par exemple une nouvelle icone grâce à un QIcon * ptr = new QIcon("fichier.png"); ta variable ne va pas se contenter (à mon sens du moins) de faire pointer un quelconque pointeur interne vers le contenu du fichier qui se trouve dans l'exécutable: elle va réellement lire ce contenu.

Et pour ce faire, elle aura recours à l'allocation dynamique de la mémoire afin de disposer de suffisamment d'espace pour représenter l'ensemble du contenu de la mémoire.

Cela se fera évidemment à chaque fois que tu créeras une variable de type QIcon (pour reprendre l'exemple) et l'espace mémoire utilisé pour représenter (en interne, au niveau de ta variable QIcon) ne sera libéré que quand la variable sera réellement détruite.

On peut donc se dire que si tu crées N variable de type QIcon qui utilisent le même fichier .png, tu utiliseras N fois l'espace mémoire nécessaire à la représentation en mémoire du contenu du fichier png en question et que la mémoire sera libérée au gré de la destruction des variables de type QIcon

Je peux évidemment me tromper très lourdement, mais je ne crois pas que ce soit le cas pour la simple et bonne raison qu'il est tout à fait possible de charger des icones qui ne sont pas forcément reprises dans le fichier rc

[Christophe]

Merci pour ta réponse Koala.

Il y avait 2 solutions possibles :
- perte du pointeur sur l'ancien objet, l'objet restant en mémoire mais inaccessible, si l'on veut "garder" l'ancienne version, il faut en avoir une copie, et non pas son pointeur
- destruction de l'ancien objet lors du remplacement de celui-ci, impossible donc de garder l'ancienne version.

Je connais donc maintenant le comportement par défaut. Si celui-ci ne me convient pas, il me suffit de dériver l'objet.