Discussion :

[Eldynn]

Bonjour à tous,

J'ai un problème pour appliquer ce que je trouve sur internet par rapport à la suppression d'un élément d'un vector, ici un pointeur vers un objet.

Le but est de supprimer lors de la destruction d'un enfant le pointeur contenu dans un vector membre du parent, je fais quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
this->parent()->liste().erase(std::remove(this->parent()->liste().begin(), this->parent()->liste().end(), [this](Item *item) { return item == this; }), this->parent()->liste().end());

L'erreur avec ce code est "no match for 'operator==' (operand types are 'Item*' and 'const Item::remove()::<lambda(Item*)>')"

EDIT: Bon finalement j'ai fait un for et un if pour trouvé mon pointeur plutôt que d'utiliser std::remove.

[jo_link_noir]

Sinon, pour utiliser un prédicat, on utilise les versions suffixées de _if: std::remove_if.

[koala01]

Salut,

La première chose, c'est que ce n'est pas l'enfant qui devrait s'occuper de s'enlever lui-même de la liste des enfants de son parent...

L'idéal serait que l'enfant se contente de signaler "je me casse, chiao" à son parent, et que ce soit le parent qui s'occupe d'enlever effectivement l'enfant qui s'en va de la liste de ses enfants.

Cela ne te parait-il pas plus logique, rien qu'à l'exprimer de la sorte

Dans cette optique, le parent aurait une fonction

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
void Parent::removeChild(Child * child){
    std::remove_if(allChildren_.begin(), allChildren_.end(), child);
}

et l'enfant se contenterait d'appeler parent->removeChild(this);

Maintenant, il est sans doute encore possible de faire autrement. Et il y a "toutes les chances" que cette alternative soit bien plus facile à gérer pour toi.

C'est en effet le contenu qui dépend du contenant et non l'inverse : l'ordre logique voudrait que ce soit le contenant (le parent, dans le cas présent) qui décide de détruire un des éléments qu'il contient (un de ses enfants, dans le cas présent) en le supprimant de la liste de contenu. Cela permettrait d'ailleurs de laisser "autre chose" (qui ne soit ni le contenu ni le contenant) décider ... quels éléments doivent être supprimer du contenant.

Cela aurait en outre l'énorme avantage de permettre à l'enfant de ne plus avoir besoin de connaitre son parent

En travaillant de la sorte, tu pourras encore te simplifier la vie (et éviter bien des bugs sur lesquels tu t'arracheras les cheveux) en utilisant les pointeurs intelligents (smart pointers, en anglais), comme std::unique_ptr ou le couple std::shared_ptr + weak_ptr (selon tes besoins spécifiques): Lorsque le contenant (le parent) supprimera effectivement un élément de son contenu, ces classes que l'on peut qualifier de "capsules RAII" s'occuperont de libérer correctement (et efficacement) la mémoire allouée à l'élément en question, et d'éviter bien des problèmes.

Enfin, il faut savoir que l'utilisation de pointeurs en générale doit être évitée chaque fois qu'il est possible de le faire. Il se peut que tu aies effectivement besoin de pointeurs dans le cas présent, si la classe dont tu nous parle intervient dans une hiérarchie de classes. Mais si ce n'est pas le cas, tu n'as absolument aucune raison de maintenir la liste des enfants sous la forme d'un std::vector<Object *> (ou, mieux, d'un std::vectror<std::unique_ptr<Object>>).

Si ta classe n'intervient pas dans une hiérarchie de classes, la solution la plus simple sera toujours la meilleure, et un simple std::vector<Object> fera tout aussi bien l'affaire

[Bousk]

Enfin, il faut savoir que l'utilisation de pointeurs en générale doit être évitée chaque fois qu'il est possible de le faire. Il se peut que tu aies effectivement besoin de pointeurs dans le cas présent, si la classe dont tu nous parle intervient dans une hiérarchie de classes. Mais si ce n'est pas le cas, tu n'as absolument aucune raison de maintenir la liste des enfants sous la forme d'un std::vector<Object *> (ou, mieux, d'un std::vectror<std::unique_ptr<Object>>).

Si ta classe n'intervient pas dans une hiérarchie de classes, la solution la plus simple sera toujours la meilleure, et un simple std::vector<Object> fera tout aussi bien l'affaire

Si la classe doit s'enregistrer dans une sorte de manager, l'utilisation de pointeur est quasiment obligatoire. Tu enregistres le this, tu ne veux pas en faire une copie.
La seule alternative c'est si ta classe est utilisé en shared_ptr, il vaut mieux enregistrer un weak_ptr. J'adorerais un unique_weak_ptr, mais la chose la plus proche que l'on ait serait un pointeur de pointeur.

[koala01]

A priori, il y aurait alors un problème d'inversion de dépendances, car ce n'est pas à la donnée de savoir qu'elle doit être enregistrée dans une sorte de manager...

Ou, en tout cas, ce n'est certainement pas à elle de décider de s'y enregistrer, car je peux comprendre qu'elle ait connaissance du manager (et encore!) pour certains usages qui n'auraient rien à voir avec l'enregistrement (ou le "désenregistrement") afin de communiquer avec lui.

Je dis "et encore", car, dans l'idéal, ce genre de communication entre un objet quelconque et le manager serait sans doute bien mieux mis en place sous la forme d'un système de signaux et de slots ou sous la forme d'un patron de conception "médiateur"

(en outre, dans le cas présent, nous avons affaire à une relation parent/ enfant, non à une relation manager / managé )