Encapsuler une list dans une class

Bonjour,

J'ai une class A:

Code:

---

1 2 3 4 5 6 7 8 9

class A { public: const std::list<B> &getList() const{return list;} void removeElementFromList(std::list<B>::const_iterator it){/*???*/};   private: std::list<B> list; };

---

Grace à la méthode getList(), je peux parcourir la liste private 'list' à l'aide d'un const_iterator.
Ma question: comment supprimer un élement de cette liste à partir d'un const_iterator à l'aide de la méthode removeElementFromList?

Biensur, je ne veux pas qu'il soit possible de supprimer un élément de la liste en dehors de ma class 'A'.

Merci d'avance.

Bonjour,

Tu as essayé la fonction list::erase ? Ça devrait marcher.

Code:

---

1 2 3 4

void A::removeElementFromList(std::list<B>::const_iterator it) { list.erase(it); }

---

Je viens de tester et ça ne fonctionne pas.
J'ai le droit à cette erreur: 'no matching function for call....'

Il faudrait un peu plus de détails sur l'erreur générée. Quelle fonction n'est pas trouvée ?

Car la solution proposée par zenux est correcte. Je pense que tu dois avoir fait une petite erreur de frappe quelque part ou alors ça vient d'une autre partie de ton code ;)

Je le verrai bien venir d'un

Code:

---

1 2 3

list<B> l = a.getList() list<b>::const_iterator w = list.find(42); // l'erreur étant ici: la liste est copiée. a.removeElementFromList(w);

---

Bref, tu ne devrais pas exposer ta liste, mais plutôt fournir les fonctions de recherche qui ont du sens histoire de garder de la cohérence.

Merci pour vos réponses. Voici mon code source en entier:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14

#include <list> class A{ public: void removeElementFromList(std::list<int>::const_iterator it) { list.erase(it); } private: std::list<int> list; };   int main(){ return 0; }

---

Compilé avec g++:

Citation:

---

greg@greg-laptop:/home/greg$ g++ test.cpp
test.cpp: In member function ‘void A::removeElementFromList(std::_List_const_iterator<int>)’:
test.cpp:7: error: no matching function for call to ‘std::list<int, std::allocator<int> >::erase(std::_List_const_iterator<int>&)’
/usr/include/c++/4.4/bits/list.tcc:107: note: candidates are: std::_List_iterator<_Tp> std::list<_Tp, _Alloc>::erase(std::_List_iterator<_Tp>) [with _Tp = int, _Alloc = std::allocator<int>]
/usr/include/c++/4.4/bits/stl_list.h:1092: note: std::_List_iterator<_Tp> std::list<_Tp, _Alloc>::erase(std::_List_iterator<_Tp>, std::_List_iterator<_Tp>) [with _Tp = int, _Alloc = std::allocator<int>]

---

La fonction erase avec un const_iterator n'existe pas d'après http://www.cplusplus.com/reference/stl/list/erase/ .

Citation:

---

Bref, tu ne devrais pas exposer ta liste, mais plutôt fournir les fonctions de recherche qui ont du sens histoire de garder de la cohérence.

---

En effet, c'est pas top comme solution mais je ne vois pas de bonne solution pour ce que je veux faire. En fait, ma classe qui contient la liste est une forme geométrique:

Code:

---

1 2 3 4 5 6

class FormeGeometrique{ public: // methodes... private: std::list<Triangle> triangles; }

---

Ensuite, j'ai plusieurs algorithmes qui peuvent modifier cette forme géométrique. Pour que ces algos puissent fonctionner correctement, j'ai besoin de leur fournir la liste des triangles et la possiblitée d'ajouter ou supprimer des triangles. Comment faire ça proprement ?

Merci d'avance.

Citation:

---

Envoyé par zenux

La fonction erase avec un const_iterator n'existe pas d'après http://www.cplusplus.com/reference/stl/list/erase/ .

---

Pour altérer le contenu de la list, il faut utiliser un iterator et non const_iterator.

Avec un const_iterator, tu ne peux pas modifier le container (ajout/suppression) ni modifier le contenu de l'un de ses éléments. C'est pour cela qu'il n'existe aps de méthode erase prenant un const_iterator.

Parfait, on est donc d'accord sur ce point :ccool: .
On en revient donc à la question initiale: comment encapsuler correctement une liste tout en fournissant un accès en lecture à cette liste + fonction d'ajout et de suppression ?

Oups.
J'ai tellement trouvé ce comportement aberrant que j'ai voté négatif. Et pourtant ... c'est bien ce que l'on trouve dans le standard de 98/03.
Au temps pour moi donc -- vu que l'on ne peut pas annuler un vote (d'ailleurs si un modo passait par là...)

[À ma décharge, cette aberration a été fixée pour le prochain standard]

Sinon, zenux, tu peux exposer une interface réduite de la liste (-> begin/end (ou autre équivalent à base de ranges), ce qui ne change pas grand chose au fond. Ton truc reste une liste quelque part si je comprends bien.

Salut,

Pour encapsuler correctement une collection, tu dois commencer par... ne jamais permettre à l'utilisateur de la récupérer d'une quelconque manière.

L'idéal étant même de "cacher" le type de collection réellement manipulé à l'utilisateur.

Pour y arriver, il est donc intéressant de définir dans la classe:

• des alias de type sur les itérateurs constants et non constant de ta liste (ou de toute autre collection)
• Les fonctions begin et end en version constante et non constante (si cela a du sens)
• Les fonctions d'ajout et de retrait d'un élément de la liste (si cela a du sens)
• Les fonctions de recherche d'un élément en version constante et non constante. (si cela a du sens)
• Eventuellement (si cela a un sens) un constructeur de la classe prenant un "range" d'éléments capable de s'adapter aux itérateurs de n'importe quelle solution.
• Les fonctions de manipulations qui t'intéressent

Au final, ta classe ressemblerait à quelque chose comme

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54

class MaClass { public: // un type d'itérateur en version non constante (facultatif) typedef std::list<Element>::iterator iterator; // un type d'itarateur en version constante (plus ou moins obligatoire) typedef std::list<Element>::const_iterator const_iterator; // un constructeur "sympa" utilisant des iterateurs template <typename iter> MaClass(iter b, iter e):items_(b,e){} // les fonctions begin et end en version constante const_iterator begin() const{return items_.begin();} const_iterator end() const{return items_.end();} // les fonctions begin et end en version non constante (facultatif) iterator begin(){return items_.begin();} iterator end(){return items_.end();} // les fonctions d'ajouts et de suppression (selon besoins) void push_fron(Element const & e){items_.push_front(e);} void push_back(Element const & e){items_.push_back(e);} void insert(iterator i, Element const & e){items_.insert(i,e);} template <typename it> void insert(iterator i, it b, it e){items_.insert(i,b,e);} void erase(iterator it){items_.erase(it);} void erase(iterator b, iterator e){items_.erase(b,e);} // la fonction de recherche en version constante const_iterator find(Un_type const & value) const { const_iterator it=items_.begin(); while(it!=items_.end()) { if(it->getValue()==value) return it; ++it; } return items_.end(); } // la fonction de recherche en version non constante (si utile) iterator find(Un_type const & value) { iterator it=items_.begin(); while(it!=items_.end()) { if(it->getValue()==value) return it; ++it; } return items_.end(); } // quelques fonctions qui seront toujours utiles size_t size() const{return items_.size();} bool empty() const{return items_.emty();} private: std::list<Element> items_; };

---

Merci beaucoup.
J'aime bien l'idée de cacher le type de la collection grâce à un typedef.

C'est effectivement une idée des plus sympathiques...

En effet, tant que tu gardera la même interface pour la classe et que tu veillera à utiliser des collections compatibles (car certains types de collection ne présentent pas certaines fonctions), tu pourra à tout moment décider de changer la manière dont ta classe manipule effectivement les différents éléments sans avoir besoin de retoucher au code qui utilise la classe.

Cela te permet donc de travailler en accord avec le principe OCP (Open Close Principle : un code doit être ouvert à l'évolution, mais fermé à la modification).

Cela te permet également de respecter la loi Demeter qui a pour but de t'inciter à n'exposer que "le stricte minimum requis" pour tes classes.

Dans le cas présent, tu arrives à n'exposer que les fonctions qui sont absolument nécessaires à la gestion des éléments au sein de la classe, sans avoir besoin d'exposer... la collection elle-même, ce qui te permet d'éviter les copies inutiles ainsi que le fait que l'utilisateur ne la manipule de manière "non prévue"