STL Problème d'itérateur

Version imprimable

25/02/2011, 10h17
Pg043

STL Problème d'itérateur

Bonjour à tous,

Je travaille sur l'implémentation d'un projet en C++ et j'ai quelques soucis avec les iterateurs de STL (c'est la première fois que je rencontre ce genre de problème). Je l'expose.

J'ai une classe virtuelle pure VirtClass et deux classes qui héritent de VirtClass : Class1 et Class2 !

Ensuite, j'ai un vecteur de pointeur sur VirtClass qui contient les instances des deux classes Class1 et Class2 : vector<VirtClass*> vec;

Lorsque je veux parcourir ce vecteur avec un iterator, impossible : la compilation se passe bien mais à l'exécution, j'ai un message d'erreur de Visual : vector iterators incompatible. Idem avec le const_iterator !

Le pire dans tout ça, c'est que si je passe par une boucle for de i = 0 à vec.size(), ça fonctionne !!!

Je souhaiterai comprendre pourquoi l'iterator ne fonctionne pas.
Je vous remercie par avance.
25/02/2011, 10h20
r0d

Bonjour,

ce que tu essaie de faire est parfaitement faisable. Il s'agit donc d'un problème dans ton code. Pourrais-tu nous le montrer?

Ok,

Voici la déclaration de VirtClass :

Code:

1
2
3
4
5
6
7
8
9
10
 
class VirtClass 
{
protected:
	int n;
 
public:
	virtual void extract() = 0;
	int getN() const { return n; }
};

Voici la déclaration de Class1 :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Class1 : public VirtClass
{
protected:
	vector<string> strs;
 
public:
	Class1 () 
	Class1 (VirtClass* v) { n = v->getN(); }
 
	~Class1 () { }
 
	void extract() { }
};

Et celle de Class2 :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
class Class2 : public VirtClass
{
protected:
	vector<OtherObj*> objs;
 
public:
	Class2 () 
	Class2 (VirtClass* v) { n = v->getN(); }
 
	~Class2 () { }
 
	void extract() { }
};

Ces trois classes sont sérializées avec Boost !

Je ne vois pas, désolé.
Afin d'essayer de trouver le problème, j'ai testé le code suivant, avec le niveau max pour les warning, et ça fonctionne parfaitement, sans warning.

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
#include <iostream>
#include <vector>
 
using namespace std;
 
class VirtClass 
{
protected:
	int n;
 
public:
	virtual void extract() = 0;
	int getN() const { return n; }
};
 
class Class1 : public VirtClass
{
public:
	Class1() : VirtClass() { n = 0; }
	void extract() { cout << "extract Class1" << endl; }
};
 
class Class2 : public VirtClass
{
public:
	Class2() : VirtClass() { n = 0; }
	void extract() {  cout << "extract Class2" << endl; }
};
 
int main(int argc, char* argv[])
{
	vector< VirtClass*> v;
	for ( int i = 0; i < 20; ++i )
		if ( i%2 == 0 )
			v.push_back( new Class1 );
		else
			v.push_back( new Class2 );
 
	for ( vector< VirtClass*>::iterator it = v.begin(); it != v.end(); ++it )
		(*it)->extract();
 
	// nep as oublier de détruire le contenu de v sinon ya une fuite mémoire là
	for ( vector< VirtClass*>::iterator it = v.begin(); it != v.end(); ++it )
		delete (*it);
 
	cin.get();
	return 0;
}

Donc je ne sais pas, c'est peut-être à cause* de boost::serialize, que je ne connais pas.

* lire "à cause d'une mauvaise utilisation de"

Ok, merci, alors, je viens d'utiliser le code fourni et ça fonctionne, je le confirme.

Maintenant, j'ai apporté une petite modification : j'ai une classe Cont qui contient le vector<VirtClass*> vec;

Si je mets vec en public et que j'utilise push_back pour ajouter des item, ça fonctionne. Mais dès que je le passe en private et en utilisant le getter et la méthode d'ajout, ça ne fonctionne plus :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 class Cont { public: vector<VirtClass*> vec; public: Cont() {} ~Cont() {} public: // Getters vector<VirtClass*> getVec() const { return vec; } public: void addClass(VirtClass* c) { vec.push_back(c); } };
Ensuite, dans le main, cc4 fonctionne et cc3 plante :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 Cont cc4; cc4.vec.push_back(new Class1); cc4.vec.push_back(new Class1); cc4.vec.push_back(new Class2); for(vector<VirtClass*>::iterator it = cc4.vec.begin(); it != cc4.vec.end(); ++it ) (*it)->extract(); Cont cc3; cc3.addClass(new Class1); cc3.addClass(new Class1); cc3.addClass(new Class2); for(vector<VirtClass*>::iterator it = cc3.getVec().begin(); it != cc3.getVec().end(); ++it ) (*it)->extract();
Pourtant, il me semble que le getter est bon !!!

[EDIT] : je n'utilise plus la serialization dans ces exemples !!

Citation:
Envoyé par Pg043
Code:

1 2 public: // Getters vector<VirtClass*> getVec() const { return vec; }
Le mot important est const.
Citation:
cc3 plante :
Code:

1 2 3 4 // [...] for(vector<VirtClass*>::iterator it = cc3.getVec().begin(); it != cc3.getVec().end(); ++it ) (*it)->extract();
Le mot important devrait être const_iterator.

Et comme extract() n'est pas const tu auras une erreur ;-).

25/02/2011, 12h00
Pg043

Citation:

Envoyé par N i h i l

Le mot important est const.

Le mot important devrait être const_iterator.

Et comme extract() n'est pas const tu auras une erreur ;-).

Merci, mais j'ai essayé d'utiliser un const_iterator et ça ne change rien !
D'autant plus que l'erreur apparait avant l'appel à extract()
25/02/2011, 12h01
Arzar

Bonjour,

Citation:

Envoyé par N i h i l

Le mot important est const.

const n'est pas la cause du plantage.

Citation:

Envoyé par Pg043

Code:

vector<VirtClass*> getVec() const { return vec; }

Pourtant, il me semble que le getter est bon !!!

Non il n'est pas bon. Le problème c'est que le getter renvoie une copie de vec.
Donc ce code :

Code:

for(vector<VirtClass*>::iterator it = cc3.getVec().begin(); it != cc3.getVec().end(); ++it )

récupère l'itérateur begin et end sur deux copies temporaires de vec, copies qui ne sont plus valables ici :

Code:

(*it)->extract();

Un getter doit renvoyer une référence (constante ou non) sur la donnée membre :

Code:

const vector<VirtClass*>& getVec() const { return vec; }
25/02/2011, 12h09
Pg043

Merci Arzar, il semble que cela fonctionne maintenant !

Pour aller plus loin, si maintenant je veux utiliser un iterator pour parcourir et modifier mon vector, il suffit d'ajouter un deuxième getter comme ceci ?

Code:

vector<VirtClass*>& getVec() { return vec; }
25/02/2011, 12h11
r0d

Citation:

Envoyé par Arzar

Un getter doit renvoyer une référence (constante ou non) sur la donnée membre

J'ai failli faire la même remarque, mais en fait je pense que ce n'est pas forcément systématique. Parfois on peut vouloir renvoyer une copie. Par exemple si on veut appliquer des algorithmes qui modifient la structure renvoyée, mais sans modifier la structure membre de la classe; typiquement pour faire des prédictions.
Par contre dans ce cas, c'est sûr que le nom de la fonction serait plutôt GetCopy ou quelque chose dans le style, pour expliciter clairement que l'appelant reçoit une copie.

Mais comme Pg043 ne nous dit rien, ni de ses intentions, ni de la ligne qui pose problème, ni de la nature de l'erreur, il est difficile de se prononcer.

Et puis il y a bien d'autres problèmes. Par exemple, le fait que, lorsqu'un objet est destiné à être stocké dans un conteneur, il faut faire particulièrement attention aux constructeurs, or ici il n'y a pas ni de constructeur par copie ni d'opérateur d'assignation. Ou le fait, étrange, mais peut-être légitime (encore une fois, il est impossible de se prononcer vu le manque d'information) que la variable membre n de la classe mère soit initialisée par les classes filles.
25/02/2011, 12h15
r0d

Citation:

Envoyé par Pg043

Merci Arzar, il semble que cela fonctionne maintenant !

Pour aller plus loin, si maintenant je veux utiliser un iterator pour parcourir et modifier mon vector, il suffit d'ajouter un deuxième getter comme ceci ?

Code:

vector<VirtClass*>& getVec() { return vec; }

Oui, mais ça casse l'encapsulation.
Outre les problèmes de sécurité et de stabilité, lorsqu'on encapsule un conteneur dans une classe, c'est parce qu'on souhaite que ce soit cette classe qui gère ce conteneur. Si ce n'est pas le cas, le conteneur n'a rien à faire dans cette classe.
25/02/2011, 12h20
Pg043

Ok ok r0d, merci de ton aide, et désolé pour le manque d'info !

Citation:

Et puis il y a bien d'autres problèmes. Par exemple, le fait que, lorsqu'un objet est destiné à être stocké dans un conteneur, il faut faire particulièrement attention aux constructeurs, or ici il n'y a pas ni de constructeur par copie ni d'opérateur d'assignation. Ou le fait, étrange, mais peut-être légitime (encore une fois, il est impossible de se prononcer vu le manque d'information) que la variable membre n de la classe mère soit initialisée par les classes filles.

Ceci est bien géré !

En fait, pour comprendre l'erreur, j'ai repris ces quelques classes dans un projet que je voulais le plus light possible !

Citation:

Mais comme Pg043 ne nous dit rien, ni de ses intentions, ni de la ligne qui pose problème, ni de la nature de l'erreur, il est difficile de se prononcer.

Il me semble avoir décris le problème dans le premier post !

En tout cas, merci beaucoup à tous pour votre aide.