Discussion :

[kase74]

Bonjour, Bon, je pensais avoir compris les conteneurs, mais voila, ca ne marche pas comme je le veux.
Voici exactement mes declarations :

Code :

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

1
2
3
4
5
class CCell;
typedef std::list<CCell> TCellsList;
typedef TCellsList::iterator TIteratorOnACell;
typedef std::list<TIteratorOnACell> TiterCellsList;
typedef TiterCellsList::iterator TIteratorOnAniterCell;

Ce que je veux faire ? :
j'ai une classe CCell, je veux avoir une list d'instances de CCell => TCellsList.
TIteratorOnACell est mon outil de parcours de ma liste de CCell.

Avant de détailler la suite, je vous explique l'objectif recherche :
J'ai une liste de cellules "generale". Et je veux pouvoir distinguer au sein de cette liste, des sous-listes. Mais je ne veux pas creer de doublons de cellules. Donc, je m'etais dis, mes sous-ensembles doivent etre des liste de pointeur faisant reference a un element de ma liste generale. Ca va, tous le monde me suit ? A ce moment la, je me suis dis, bon, les iterateurs, ce sont des pointeurs !!! Donc si je fais une liste d'iterateurs ... Et c'est la je pense qu'est mon erreur.
TiterCellsList c'est ma liste d'iterateurs. (mes sous-ensembles)
TIteratorOnAniterCell mon outil de parcours d'un sous-ensemble.

Maintenant, je remarque que :
- je parcours ma liste generale de cellule sans probleme, les donnees, tout est correcte.
- je parcours une sous liste, le nombre d'element est correcte mais les donnees c'est n'importe quoi !

J'ai bien verifie ma procedure d'ajout d'elements d'une sous liste et je n'y vois rien de speciale. J'en conclu que l'utilisation des listes d'iterateurs est une erreur, surement parceque ceux ci sont ephemeres et que je perds la liaison avec l'element de la liste generale. Le solution serait donc de faire une liste de bon vieux pointeurs !

Je sais comment regler le pb, a priori. Mais cette histoire me titille alors est ce que vous pourriez me confirmer ou imfirmer mes soupcons pour ma culture svp, et surtout pour etre sur de bien comprendre, cette fois ci le fonctionnement des iterateurs.

merci d'avance pour vos reponses.

[3DArchi]

J'en conclu que l'utilisation des listes d'iterateurs est une erreur, surement parceque ceux ci sont ephemeres et que je perds la liaison avec l'element de la liste generale.

Les itérateurs ne sont pas fait pour être 'maintenus'. Ils peuvent changer dès que tu modifies ta liste (par ajout ou suppression).

Le solution serait donc de faire une liste de bon vieux pointeurs !

Pas forcément (en plus cela risque d'introduire autant de problème que ça n'en résoud). Cela dépend du critère de tes sous-listes. Tu peux utiliser par exemple des itérateurs boost, type filter_iterator pour reconstituer ta liste. En fait, l'idée serait plutôt de travailler sur des 'filtres' pour tes différentes sous-listes.

[kase74]

Bonjour 3DArchi, merci pour ta reponse.

Tu me dis qu'il risque d'y avoir plus de problemes avec les pointeurs, mais lesquels, je ne vois pas pourquoi ?

Je vais regarder comment fonctionnent les iterateurs de filtre, je ne les connais pas.

[Goten]

Parce qu'en C++ on évite le plus possible d'utiliser les pointeurs. Plus t'en a plus tu as des risques de segfault et autres joyeuseté.
Ou alors utilisé des pointeurs 'enrobé', les smart pointeurs.

[loufoque]

Les itérateurs ne sont pas fait pour être 'maintenus'. Ils peuvent changer dès que tu modifies ta liste (par ajout ou suppression).

C'est faux. Tu confonds vector et list. Seul assign invalide les itérateurs.

Ensuite j'ai du mal à voir comment un itérateur définit un sous-ensemble. Il faudrait une paire d'itérateurs (en supposant qu'il n'y a pas de "trou" dans le sous-ensemble).

[kase74]

Bonjour, merci pour vos reponses.

C'est faux. Tu confonds vector et list. Seul assign invalide les itérateurs.

Ca veut dire que ca peut marcher mon principe ?

Ensuite j'ai du mal à voir comment un itérateur définit un sous-ensemble. Il faudrait une paire d'itérateurs (en supposant qu'il n'y a pas de "trou" dans le sous-ensemble).

Un iterateur ne defini pas un sous ensemble mais juste un element CCell. C'est une liste d'iterateur qui definie mon sous ensemble.

[Noxen]

Je verrais 2 manières gérer ton problème.

Tu pourrais gérer les objets dynamiquement, avec des vector de pointeurs, à condition d'encaspuler ces traitements dans une classe pour assurer une certaine sécurité, RAII et tout ça. De cette manière les sous-listes pourraient se référer aux objets eux-même plutôt qu'à des iterateurs sur les objets.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
 
vector<CCell*> generic;
vector<CCell*> specific1;
vector<CCell*> specific2;
 
CCell* pC = new CCell(type1);
generic.push_back(pC);
specific1.push_back(pC);
 
pC = new CCell(type2);
generic.push_back(pC);
specific2.push_back(pC);
 
specific2.clear();
specific1.clear();
for(vector<CCell*>::iterator it = generic.begin(); it!=generic.end(); ++it)
    delete (*it); // Récupérer le pointeur pour deleter l'objet pointé;
generic.clear();

Mais pour être vraiment prudent, il vaut mieux encapsuler la liste générique dans une autre classe, qui assure l'effacement correct des objets, notamment en cas d'erreur.

Code :

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

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 CCellManager
{
private:
    vector<CCell*> _list;
public:
    ~CCellManager(){ // Suppression du contenu dynamique par le destructeur
       clear(); // Evite la duplication de code
    }
 
    void clear(){
         for(vector<CCell*>::iterator it = _list.begin(); it!=_list.end(); ++it)
            delete (*it);
        _list.clear();
    }
 
    vector<CCell*>::iterator begin() { return _list.begin(); }
/* On pourrait même masquer le fait qu'on gère avec un vector en renvoyant
 plutôt une itérateur "maison", ou avec un typedef :
typedef vector<CCell*> cm_list; 
cm_list::iterator begin() { return _list.begin(); }
pour pouvoir éventuellement modifier l'implémentation.
*/
 
    vector<CCell*>::iterator end(); { return _list.end(); }
 
    void push_back(CCell* C) { _list.push_back(C); }
 
    void erase(CCell* C) {
        for(<vector<CCell*>::iterator it = _list.begin; it!=_list.end(); ++it)
            if((*it) == C){
                delete (*it); // Ou : delete C;
                _list.erase(it);
                break;
            }
    }
};
 
// Utilisation:
 
int main(){
    CCellManager cm;
    cm.push_back(new CCell());
    cm.push_back(new CCell());
 
    for(vector<CCell*>::it = cm.begin(); it!=cm.end(); ++it)
        (*it)->do_something(); // Ce genre d'écriture est toutefois un peu lourde, et sujete à erreur, il faut bien l'admettre.
 
    cm.clear();
 
    cm.push_back(new CCell());
 
    return 0; // A la sortie de la fonction, le destructeur de cm évitera la fuite mémoire
}

Bon, c'est juste un premier jet pour donner une idée, ce serait à affiner en fonction de ta conception, on peut certainement faire une interface plus intuitive. De plus, il faudrait se replonger dans la spécification des vecteurs, mais il est peut-être possible de faire ça sans utiliser de pointeurs, si les vecteurs instancient leurs objets une fois et ne les déplacent pas, par exemple si on ajoute ou retire des objets. Peut-être quelque chose comme ça:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
vector<CCell> generic;
vector<CCell*> specific1;
vector<CCell*> specific2;
 
generic.push_back(CCell(type1));
generic.push_back(CCell(type2));
 
for(vector<CCell*>::iterator it = generic.begin(); it!=generic.end(); ++it){
    if(it->critere_de_repartition() == type1) specific1.push_back(&(*it)); // Adresse de l'objet pointé par l'itérateur
    else if (it->critere_de_repartition() == type2) specific2.push_back(&(*it));
}
 
specific2.clear();
specific1.clear();

Un autre idée : si tous les objets de la liste générale sont forcément membres d'une sous-liste ou d'une autre, tu pourrais gérer le cycle de vie des objets dans tes sous-listes, et la liste générale serait un itérateur qui passerait en revue les différentes sous-listes.

[JolyLoic]

C'est faux. Tu confonds vector et list. Seul assign invalide les itérateurs.

Et erase invalide évidemment les itérateurs sur les éléments supprimés.

[3DArchi]

Les itérateurs ne sont pas fait pour être 'maintenus'. Ils peuvent changer dès que tu modifies ta liste (par ajout ou suppression).

Seul assign invalide les itérateurs.

Et erase invalide évidemment les itérateurs sur les éléments supprimés.

Donc, la suppression d'éléments invalide les itérateurs. Si je rajoute que splice (23.2.2.4 - 4 dans la norme) aussi, j'aurais tendance à conclure : merci d'être moins catégorique :

C'est faux. Tu confonds vector et list.

Ceci dit, je pense que maintenir une liste de pair d'itérateur ou de pointeur à côté, n'est pas une bonne idée. Il vaut mieux partir sur la définition des sous-ensemble pour les parcourir ensuite ta liste de façon 'filtrée'. En fait, la question est : comment sont définies tes sous-listes par rapport à la liste principale ?

[kase74]

Et bien j'ai pas encore eu le temps de regarder correctement le filter_iterator, mais la proposition de noxen me plait bien, c'est des pointeurs mais au moins je comprends le truc.

et que diriez vous d'une liste de pointer comme ceci :

Code :

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

1
2
3
4
typedef std::list<CCell> TCellsList;
typedef TCellsList::iterator TIteratorOnACell;
typedef std::list<TCellsList::pointer> TiterCellsList;
typedef TiterCellsList::iterator TIteratorOnAniterCell;

J'ai pas verifie ni meme essaye si la syntaxe est correcte, mais il existe bien un membre pointer au niveau des listes, pourquoi ne pas les utiliser ?

[3DArchi]

A ce moment, je te conseil de partir plutôt sur sa dernière idée - si les sous listes sont disjointes :
-> une liste de sous liste.
Ta liste est alors l'union de chacune des sous-listes.

Partir d'une liste globale et de sous-listes, avec les sous-listes étant des pointeurs/référence/itérateur sur la liste globale, c'est une prise de risque indéniable sur une incohérence entre les différents conteneurs. En un sens, c'est introduire de la redondance dans tes données.

[JolyLoic]

Donc, la suppression d'éléments invalide les itérateurs.

La nuance est qu'à la différence d'un vector pour lequel la suppression (ou l'ajout) invalide TOUS les itérateurs, pour une liste seuls les itérateurs sur les éléments effacés sont invalidés. Ce qui permet quand même de faire plein de choses.

[3DArchi]

La nuance est qu'à la différence d'un vector pour lequel la suppression (ou l'ajout) invalide TOUS les itérateurs, pour une liste seuls les itérateurs sur les éléments effacés sont invalidés. Ce qui permet quand même de faire plein de choses.

Je pense qu'il est quand même dangereux de maintenir une liste d'itérateur. Pour au - 2 raisons :
1/ C'est souvent une forme de redondance de l'information,
2/ Si d'aventure le conteneur de base est changé, ça peut passer inaperçu à la compilation et désastreux à l'exécution...

[kase74]

Le probleme c'est que je ne peux pas les classer en sous-ensemble des leur creation. Pour situer le contexte : c'est pour faire des calculs mecaniques. Les cellules sont des discretisations physiques d'elements.

L'utilisateur defini le systeme d'etude par troncon. Il defini pour chaque troncon le nombre de cellule de discretisation qu'il souhaite. je dois avoir une liste generale de toutes mes cellules pour les parcourir facilement lors d'un traitement numerique. En meme temps, je dois connaitre les cellule qui sont les conditions aux limites du systeme, celles qui sont "internes" et celles qui sont dites de jonction entre 2-3 ou n troncons.

Je ne peux pas savoir a l'avance qu'elle type de cellule l'utilisateur est en train de creer. Et puis de toute facon, une cellule peut etre amenee a evoluee si le systeme est modifie.

[kase74]

La nuance est qu'à la différence d'un vector pour lequel la suppression (ou l'ajout) invalide TOUS les itérateurs, pour une liste seuls les itérateurs sur les éléments effacés sont invalidés. Ce qui permet quand même de faire plein de choses.

Pourquoi a ce moment la j'ai des donnees erronees ? T'es bien en train de dire que ca devrait marcher avec ma premiere architecture ?

[kase74]

Apres mon dernier post, j'ai eu soudain un flash puis un gros doute.
Je suis alle verifier ma procedure de creation des sous ensembles et la le drame : je faisait des push_back(MaListeCellOrigine.end()) alors qu'il fallait faire :

Code :

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

1
2
        TIteratorOnACell iNewCell = m_CellsList.end(); --iNewCell;
        MonSousEnsemble.push_back(iNewCell);

Bon puisque ca marche ! c'est tres bien. Bien sur je precise que je prends toutes les precautions necessaires lors de suppression d'element ...

Une precision quand meme, a la destruction de ces sous ensemble, je n'ai pas besoin de faire quoi que ce soit ? Je precise que je ne veux pas que cela detruise les elements de la liste d'origine, mais seulement la sous liste qui fait references a des elements de la liste generale.

Merci encore pour toutes vos reponses et ce debat qui m'a permis de mieux connaitre encore STL.

[Arzar]

Mince j'arrive après la bataille.
Bon pour ma part j'utiliserais la solution de Noxen : Un objet Raii qui encapsule les Cell allouées dynamiquement, et des std::list<Cell*> pour la liste principale et les sous-listes.

D'abord on crée une classe générique dont le but est simplement de posséder les ressources et de les libérer proprement. (Le code qui suit est fortement inspiré de ce lien)

Code :

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

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
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
 
#ifndef RAIIRESOURCEHOLDER
#define RAIIRESOURCEHOLDER
 
template <typename T>
class RaiiResourceHolder
{
public:
 
   RaiiResourceHolder()
   {
   }
 
   ~RaiiResourceHolder()
   {
      DisposeAll();
   }
 
   T* Keep(T* p)
   {
      iterator found = find(container_.begin(), container_.end(), p);
      if(found == container_.end())
      {
         container_.push_back(p);	
      }
   return p;
}
 
void Dispose(T* p)
{
   iterator found = find(container.begin(), container.end(), p);
   if(found != container_.end())
   {
      container_.erase(found);
      DoDelete(p);
   }
}
 
void DisposeAll()
{
   while (!container_.empty())
   {
      T* p = container_.back();
      container_.pop_back();
      DoDelete(p);
   }
}
 
private:
 
   void DoDelete(T* p)
   {
      try
      {
          delete p;
      } 
      catch(...)
      {
          //  en cas d'exception.... faudrait faire qqchose
      }
}
 
   typedef typename std::vector<T*>::iterator iterator;
   std::vector<T*> container_;
 
   // Pour éviter la copie
   RaiiResourceHolder (const RaiiResourceHolder&);
   RaiiResourceHolder& operator= (const RaiiResourceHolder&);
};
 
#endif RAIIRESOURCEHOLDER

(Il y a peut être encore un peu de boulot, pour la gestion des exceptions et les objets constants)

Et un exemple basique d'utilisation :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
 
{
   RaiiResourceHolder<Cell> cellHolder;
   std::list<Cell*> cellList;
 
   // peupler la liste...
   Cell* cell = new Cell();
   cellList.push_back(cellHolder.Keep(cell));
   ...
 
    std::list<Cell*> cellSubList;
    ...
   //Faire des trucs
 
} //On sort du scope, tout est libéré correctement.

[kase74]

Merci à tous pour votre participation.