Implémentation classe d'itérateur/conteneur, soucis

J'ai plusieurs problèmes pour implémenter ma classe d'itérateur et de conteneur, je vais commencer par celui-là :

Ma classe itérateur se sert d'un indice pour accéder à l'élément courant du conteneur.

Code:

---

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

class Iterateur { public: // Construction d'un itérateur non initialisé Iterateur(); // Construction à partir d'un conteneur et de l'indice d'un élément du conteneur Iterateur( Conteneur * conteneur, size_t position ); ~Iterateur();     private: // Le conteneur Conteneur * m_conteneur;   // Position courante dans le conteneur size_t m_position;

---

Et ma classe Conteneur permet de renvoyer des Iterateur const ou non const :

Code:

---

1 2 3 4 5 6 7 8

class Conteneur { public: iterator begin(); const_iterator begin() const; iterator end(); const_iterator end() const; };

---

Lorsque j'implémente ma méthode begin() non const, je passe this dans le constructeur d'Iterateur que je renvoie, mais pour la méthode const, il faudrait que je passe par un const_cast<>, or je me dis que le const_cast montre que j'ai mal pensé la chose.

Des avis ?

hello,

question bête: pourquoi t'utilises pas la STL?
dans les vectors tout existe déjà il me semble :?

Au boulot, un simple include de la STL pose des problemes de compilation très obscurs (code vieux, incompatibilité avec les MFC etc.).

Dans mon projet, il existe déjà des conteneurs de type Map, Tableau, Set etc. que je suis tenu d'utiliser.

Je peux toutefois utiliser les algos STL dans les cpp ce qui me simplifie pas mal.

Donc ce que je fais, c'est des wrappers Conteneurs Perso -> Interface STL. avec les itérateurs qui vont bien.

Oui. Regarde comment font les autres.
P.ex. en m'inspirant de la stdlib de GCC, j'avais pondu cela: http://hermitte.free.fr/Info/C++/lib...cular_list.hpp

Merci Luc.

La premiere chose que je remarque dans ton implémentation, c'est que tu n'as pas besoin de redéfinir de classe d'itérateur, puisque tu pars du principe que stl_holder possède une interface stl et, donc, propose déjà un type d'itérateur que tu peux te contenter de réutiliser.

Cependant, c'est intéressant, je vois que tes itérateurs de début et de fin sont membres de la classe, que tu les mets à jour lors de modifications et que tu te contentes de les renvoyer dans begin() et end() -/+ const.

Effectivement c'est la solution que je vais adopter.

Certainement à plus tard pour de nouvelles (més)aventures.

Tout le boulot est dans iterator_base -- et dans le type qui en hérite.

Après le champs value_ est un itérateur vers un autre conteneur à la STL, comme il aurait pu s'agir d'un indice ou d'un pointeur. Ca, c'est le détail d'implémentation.

En fait, ce que je veux faire, c'est ce fait ton policies::storage::stl_container<> à la difficulté près que mes conteneurs membres ne respectent pas la syntaxe stl et ne résonnent pas en itérateurs.

Mais ça va, je m'en sors.

??
Alors il y a policies::storage::static_array<> qui ne repose pas sur un conteneur STL.
Il expose un itérateur trivial (un pointeur quoi) pour des classes qui sont bâties autour.

Bref. Si tu trouves ton bonheur, c'est l'essentiel.

EDIT: Sur le site d'Angelika Langer, tu trouveras des articles dédiés aux itérateurs.

J'ai peut-être mal regardé ton code, mais il me semble que c'est à peu près ce que j'ai codé (i.e. une politique de stockage), mais moi je dois en plus faire un adapter.

En gros, dans un framework, j'ai des classes de tableaux, triés, associatifs, chainés etc.

Etant contraint d'utiliser ces classes plutôt que les tableaux standards (inclusion problématique dans certains .h du projet), je ne peux pas bénéficier des algorithmes standards.

Exemple : std::set correspond en gros à TabUniqueTrie

J'aimerais bien pouvoir faire des std::for_each sur mon TabUniqueTrie mais, tu t'en doute, sans itérateurs défini par TabUniqueTrie, la chose n'est pas triviale. J'ai besoin d'un adapter.

Deuxieme chose, les tableaux du framework ont tout de même une interface assez cohérente entre eux. Ainsi, on peut presque toujours obtenir un élément via son index interne (un size_t), même sur une "map" (TabAssociatifTrie). Je peux donc envisager de ne faire qu'un seul (ou presque) adapter, template, qui prendrait en paramètre le type de tableau, en en proposant un par défaut.

En gros mon adapter ressemble à ça :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

template < typename T, template < typename T > class CONT > ConteneurAdapter { public: typedef Iterateur<CONT<T> > iterator; typedef IterateurConst<CONT<T> > const_iterator;   public: iterator begin(); const_iterator begin() const; iterator end(); const_iterator end() const;   private: CONT<T> conteneur_; iterator premier_; iterator dernier_; };

---

Ensuite je spécialise mes classes Iterator et IteratorConst pour les conteneurs du framework au fonctionnement un peu différent.

J'ai également un ConteneurAssociatifAdapter qui demande un paramètre template de plus pour la clef, la surchage de classe template n'étant pas prévue par le langage.

A l'utilisation ça donne cela :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

class TabDernierScores : public ConteneurAdapter<int> : // Par défaut un Tableau utilisé (style vector) { static TabDernierScores const & Instance(); };   int main() { TabDernierScores const & tab = TabDernierScores::Instance(); tab .push_back( 4 ); tab .push_back( 3 ); tab .push_back( 3 ); tab .push_back( 5 );   ConteneurAdapter<int, TabUniqueTrie> tabScoresUniques;   std::copy( tab.begin(), tab.end(), std::back_inserter( tabScoresUniques ) ); }

---

Deuxieme avantage apporté : je peux rendre plus indépendantes certaines petites batteries de tests unitaires qui utilisent des containeurs du framework. Etant donné que mes adapters fonctionnent comme la STL, je peux faire un projet indépendant utilisant la STL, puis changer juste le type de mon conteneur lorsque je passe dans mon projet. ;)