conversion raw pointer unique_ptr

Version imprimable

29/03/2015, 19h42
Kafkana

conversion raw pointer unique_ptr
Bonjour,

j'ai un objet map qui me donne diverses informations. Une de ces informations est une largeur que je récupère grâce au code

Code:

map->GetTileset(i)->GetTileWidth()

Je voulais raccourcir ce code avec
Code:

1 2 auto tileset = make_unique<const Tmx::Tileset>; tileset = map->GetTileset(i);
Mais j'obtiens l'erreur :
Code:

1 2 error: cannot convert ‘const Tmx::Tileset*’ to ‘std::unique_ptr<const Tmx::Tileset, std::default_delete<Tmx::Tileset> > (*)()’ in assignment tileset = map->GetTileset(0);
Le code suivant marche sans problème
Code:

1 2 const Tmx::Tileset* tileset = new const Tmx::Tileset; tileset = map->GetTileset(i);
Du coup, je me demande si on peut convertir un pointer en unique_ptr, ou si il vaut mieux passer par new dans le cas présent.
29/03/2015, 20h55
jo_link_noir

Pourquoi ne pas simplement copier le pointeur ? auto tileset = map->GetTileset(i);.

Mais qui est le propriétaire, la map ou celui qui fait appel à GetTileset ?
29/03/2015, 22h10
Kafkana

Alors, c'est peut être là que je ne comprend pas ce que je fais. Dans les exemples (l'objet map est créé à partir d'une bibliotèque nommée tmxparser), ils utilisent directement

Code:

const Tmx::Tileset *tileset = map->GetTileset(i);

et pas d'opérateur new. Mais, en faisant ça, on copie le pointeur et cette copie ne se désalloue pas (fuite de mémoire ?).
29/03/2015, 23h16
Bousk

Salut,

pourquoi y'aurait-il une fuite mémoire ? :weird:
Si l'objet map fournit des pointeurs, y'a fort à parier que c'est lui qui gère les Tileset. Donc si tu détruits la map, les Tileset qu'il contient seront supprimés...
Pour ça, faut lire la doc.
30/03/2015, 12h36
koala01
Salut,
Citation:
Envoyé par Kafkana

Bonjour,

j'ai un objet map qui me donne diverses informations. Une de ces informations est une largeur que je récupère grâce au code

Code:

map->GetTileset(i)->GetTileWidth()

Je voulais raccourcir ce code avec

Code:

1 2 auto tileset = make_unique<const Tmx::Tileset>; tileset = map->GetTileset(i);

Mais j'obtiens l'erreur :

Code:

1 2 error: cannot convert ‘const Tmx::Tileset*’ to ‘std::unique_ptr<const Tmx::Tileset, std::default_delete<Tmx::Tileset> > (*)()’ in assignment tileset = map->GetTileset(0);
Mais réfléchis un tout petit peu!!!
Si tu écris le code

Code:

auto tileset = make_unique<const Tmx::Tileset>;

quel sera le type que le compilateur va déduire pour tileset, selon toi ?

Je te le donne dans le mille : ce sera un std::unique_ptr<const Tmx::Tileset> !

Or, si map->getTileset renvoie un pointeur, ce sera un pointeur de type /*const */ Tmx::Tileset * Or, l'affectation et la copie sont interdites pour les std::unique_ptr, même si map->getTileset renvoyait un std::unique_ptr<const Tmx::Tileset>, tu ne pourrait pas écrire le code

Code:

tileset = map->GetTileset(i);

, parce que cela ferait appel, au mieux au constructeur de copie de std::unique_ptr (qui est désactivé, pour garantir le coté "unique"), au pire à l'opérateur d'affectation, qui est, lui aussi, désactivé pour garantir le coté unique.

Si tu veux pouvoir récupérer dans tileset le pointeur renvoyé par map->getTileset, il faut le faire correctement : en utilisant la seule fonction qui te permettra d'affecter une nouvelle adresse à ton std::unique_ptr : la fonction reset(), sous une forme qui serait sans doute proche de tileset.reset(map->getTileset(i));.

Mais, en agissant de la sorte, tu risque de "souffrir" d'un effet secondaire sans doute non désiré : l'objet sous-jacent pointé par ton pointeur (donc, celui qui se trouve à l'adresse mémoire connue par ton pointeur intelligent) sera systématiquement détruit à chaque appel de la fonction reset, car std::unique_ptr veille à ce que cela fonctionne de la sorte (c'est normal : il se considère à juste titre comme... l'unique propriétaire de l'objet sous-jacent et veille systématiquement à le détruire avant de perdre toute référence dessus ;) )
Citation:
Le code suivant marche sans problème

Code:

1 2 const Tmx::Tileset* tileset = new const Tmx::Tileset; tileset = map->GetTileset(i);
Il ne saurait pas, il n'a pas de jambes :D

Et, surtout, à moins que tu ne fasse "quelque chose" entre ces deux instructions, c'est justement là que tu as une fuite de mémoire, car tu perd toute référence à l'objet qui se trouve à l'adresse mémoire renvoyée par new au moment où tu affecte à tileset l'adresse de l'objet que map->getTileset a renvoyée. Et, si tu n'as pas pris soin de libérer correctement l'objet qui se trouve à l'adresse mémoire connue par tileset AVANT de lui affecter une nouvelle adresse mémoire, il s'agit d'une adresse mémoire que l'on ne pourra plus retrouver ;)

Citation:

Du coup, je me demande si on peut convertir un pointer en unique_ptr, ou si il vaut mieux passer par new dans le cas présent.

Ce n'est malheureusement pas avec ces deux malheureuses lignes que l'on pourra te répondre, ne serait-ce que parce qu'elles sont toutes les deux fausses, et que l'on n'a aucun moyen de savoir de quoi il retourne.

Par défaut, je recommanderais très fortement l'utilisation des pointeurs intelligents, ne serait-ce que parce que tu sembles encore loin d'avoir compris toutes les subtilités liées à l'utilisation de l'allocation dynamique de la mémoire.

Et même si tu avais compris, je recommanderais encore les pointeurs intelligents, ne serait-ce que parce que c'est un moyen simple et efficace pour obtenir un code robuste.

Mais, avant d'en arriver à ces recommandations, il y a beaucoup de questions auxquelles tu devrait apporter une réponse, dont :
- à quoi sert le new / make_unique de la première ligne :question:
- y a-t-il "quelque chose" entre les deux lignes que tu nous montre :question:
- qui est responsable de la durée de vie des pointeurs renvoyés par map :question:
- Quel est le type de map :question: une classe que tu as créée par toi-même, sur laquelle tu as un minimum de contrôle, ou une classe fournie par une bibliothèque tierce, à laquelle tu ne peux pas toucher :question:
- j'en passe, et sans doute de meilleures ;)
30/03/2015, 22h19
Kafkana

Merci pour ta réponse exhaustive.

En effet ma connaissance des pointeurs est limitée. Le type de map est fournit par une bibliothèque, je n'y ai pas accès. Mais je pense avoir eu la réponse à ma question. Quand je fais

Code:

const Tmx::Tileset *tileset = map->GetTileset(i);

la mémoire est déjà alloué dans map, je n'ai pas besoin de la réalloué. Du coup ma question n'a plus de sens. Par contre, il faut être sur de ne plus utiliser le pointeur une fois map détruite.

Merci à vous

Citation:

Envoyé par Kafkana

Merci pour ta réponse exhaustive.

En effet ma connaissance des pointeurs est limitée. Le type de map est fournit par une bibliothèque, je n'y ai pas accès. Mais je pense avoir eu la réponse à ma question. Quand je fais

Code:

const Tmx::Tileset *tileset = map->GetTileset(i);

la mémoire est déjà alloué dans map, je n'ai pas besoin de la réalloué. Du coup ma question n'a plus de sens. Par contre, il faut être sur de ne plus utiliser le pointeur une fois map détruite.

Merci à vous

Mais, ca, ce n'est a priori pas un problème, à moins que tu ne décide de placer le pointeur obtenu grâce à getTileset dans une autre collection.

En effet, map a normalement une durée de vie (beaucoup) plus longue que ne l'est la durée de vie de tileset, vu qu'elle existe déjà au moment où tu déclares ta variable tileset. Cela implique que, quoi qu'il arrive, tileset (la variable, de type pointeur sur Tmx::Tileset, et non l'objet qui se trouve à l'adresse mémoire représentée par ce pointeur ;) ) sera automatiquement détruite avant que map ne le soit (cf "portée des variables") ;)

Le seul cas un peu limite serait un code proche de
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 std::vector<const Tmx::Tileset *> ptrTab; { /* map serait créée APRES ptrTab... * Quelque part ici, dans l'ordre logique d'exécution */ for(size_t i = 0; i<map.size(); ++i){ const Tmx::Tileset *tileset = map->GetTileset(i); ptrTab.push_back(tileset); // OUPPPSS... ptrTab contient maintenant un pointeur // qui risque d'être invalidé lorsque map est détruite // (du moins, si map est responsable de la durée de vie // des éléments pointés par les pointeurs qu'elle contient) } // pas de problème ici : map existe toujours, ptrTab contient donc des pointeurs invalide /* ... */ } // CRACK !!! map est détruite ici, les pointeurs qu'elles contenait (et qui sont copiés dans // ptrTab) sont potentiellement invalidés à cause de la destructions des objets pointés // correspondants for(size_t i=0; i<ptrTab.size();++i){ ptrTab[i]->doSomething(); // BOUM !!! déférencement d'un pointeur invalide... // ==> erreur de segmentation dans le meilleur des cas // ==> comportement indéfini aux conséquences catastrophiques dans le pire des cas }
Mais attention : on arrive encore assez facilement à des situations de ce genre ;) :P