pb de vector (encore un)

Version imprimable

Bonjour,

Ca fait un certain temps que j'utilise les vector mais là, je suis face à une incompréhension total.

J'utilise une classe GLignage qui est défini suivant les règles simples des 4 (constructeur,destructeur,recopie, op=). Ca fait 1 semaine que je créé, détruit, copie des objets de cet classe et tout semble rouler pour le mieux.
Récemment, je décide de rajouter une petite méthode...voici le code (enfin le seul point qui "bug" ...) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 bool GLignage::soudure(vector<GLignage>& amas) { if(amas.size()==0) { GLignage glig=*this; GLignage glig2=glig; amas.clear(); amas.push_back(glig); amas.push_back(GLignage(glig.transseg,glig.lignage)); return 1; } }
Bon alors c'est un code con, je veux juste faire le push_back(*this) mais j'ai testé plein de détail pour être sûr que ça vient du vector. Après plusieurs heures d'analyse des variables avec mon debuggeur (sous eclipse avec les options classique C++...), j'en suis à ça : le vector passé en référence a tout ses conteneurs (_M_start, _M_finish, _M_end_of_storage) sur 0x00000000 (donc le NULL)... ce qui cause un soucis visiblement...

qq1 a-t-il déjà rencontré ça? Comment passé à travers?

Merci d'avance.

09/01/2008, 08h59
MatRem

Il faudrait que tu montres comment tu appelles GLignage::soudure.

Sinon pour le type bool il existe true et false ;).
09/01/2008, 10h34
Pacorabanix

et ta fonction ne retourne rien si le test echoue!

PS à quoi sert : GLignage glig2=glig; ?

OK

Alors, pour le PS... à rien, c'était pour vérifier la recopie dans le debuggeur et s'assurer que *this passait bien
Je le rappele, je veux juste faire un amas.push_back(*this);

Pour l'autre demande... elle est également légitime :
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 //je peux extraire du code cette partie où se situe le pb... vector<GLignage> recup_tmp; vector<GLignage> recup_temp; //[...] du code sans liaison avec les objets du pb //une fonction qui remplit recup_temp... au moins 1000 lignes de code en tout //alors... mais validé et testé avec succès (50 tests, c'est à dire 2 fois //chaque configurations possibles). Avec le debuggeur, on peut observer que //l'adresse est inchangée (bonne nouvelle :D) et que les conteneurs sont bien //remplis dans un cas de remplissage et inchangé sinon... if(recup_temp.size()==0) { //code... blablabla } else { //ressouder for(vector<GLignage>::iterator ite=recup_temp.begin(); ite<recup_temp.end();++ite) { if(!((*ite).soudure(recup_tmp))) {// le pb est là! recup_tmp.push_back(*recup_temp.begin()); } } }
Donc je recopie simplement recup_temp dans recup_tmp... avec une gestion de cas lié à ma classe GLignage...simple pourtant!
... mais pourquoi des conteneurs sur NULL?! Ca par contre, c'est la première fois! Normalement, faire un vector<truc> vect; ... ça devrait pas.

09/01/2008, 15h51
Gotmere

Citation:

Donc je recopie simplement recup_temp dans recup_tmp... avec une gestion de cas lié à ma classe GLignage...simple pourtant!
... mais pourquoi des conteneurs sur NULL?! Ca par contre, c'est la première fois! Normalement, faire un vector<truc> vect; ... ça devrait pas.

bonjour, si le debuggeur te signal comme lieu de crash un lieu comme : vecteur<truc>vect; ce qui est normalement sain, ça veut dire que le probléme est ailleurs. ça peut etre un memory corruption provoqué par un autre pointeur, et dont les symptomes n'apparaissent qu'un peu plus loin, dans une ligne portant saine.

je te propose de revoir le parcours de ton programme et de ne pas te focaliser seulement sur le point qui cause le crash visiblement.
09/01/2008, 17h26
DEVfan

Ouais... j'ai essayé de changer de place... et en fait j'ai pareil.
C'est donc lié à qq chose d'intrinsèque à mon code.

Eclipse me dit : Attempt to take contents of a non-pointer value.
... j'ai toujours un vecteur initialisé sur des conteneurs vides.

je passe dans ces fonctions un "vector<GLignage>& vect". Dans une autre fonction ou je fais pareil, ça pose pas de problème. Dans les 2 cas, je fais simplement la définition du vect avant de le transmettre. Si c'était ça, ça devrait le faire dans les 2 cas.

J'suis vraiment bloqué :(
09/01/2008, 17h44
befalimpertinent

Fais vois le code du constructeur de recopie et de l'opérateur d'affectation de GLignage.
C'est souvent ici que ce situe ce genre de problème.

oui :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
//_____Constructeur de recopie_____//   
 GLignage(const GLignage& glig)
   {
    if(&glig!=this)
      {
       transseg=glig.transseg;
       //lignage.clear();
       lignage=glig.lignage;
      }    
   }
 
//_____Operateur d'affectation_____//   
 GLignage& operator=(GLignage& glig) 
   {
    if(&glig!=this)
      {
       transseg=glig.transseg;
       lignage=glig.lignage;
      }
    return *this;
   }

10/01/2008, 17h17
Gotmere

Citation:

Envoyé par DEVfan

Ouais... j'ai essayé de changer de place... et en fait j'ai pareil.
C'est donc lié à qq chose d'intrinsèque à mon code.

Eclipse me dit : Attempt to take contents of a non-pointer value.
... j'ai toujours un vecteur initialisé sur des conteneurs vides.

je passe dans ces fonctions un "vector<GLignage>& vect". Dans une autre fonction ou je fais pareil, ça pose pas de problème. Dans les 2 cas, je fais simplement la définition du vect avant de le transmettre. Si c'était ça, ça devrait le faire dans les 2 cas.
J'suis vraiment bloqué :(

oui justement! c'est pas à cause du vecteur que tu passe en paramètre, puisque tu le crée juste avant. j'avais aussi exactement le meme problème, et je l'ai réglé en parcourant mon programme depuis le début et en arrangeant tout ce qui me parait louche (meme si il a l'air de marcher) et quand j'ai terminé les arrangements, le problème a disparu. le code du vecteur etait juste le bouc émissaire en effet :D
10/01/2008, 18h17
DEVfan

Soit!

Mais alors qu'entends-tu par arrangements? ...Parce que mes opérateurs (recopie, =, etc.) me semblent bon et stl est sensé être sûr... Je vais faire un test à part sans aucun pointeur pour pister une éventuelle fuite ... mais avoir une erreur après 5000 lignes de codes... ça va être long pour trouver ça!!:?
11/01/2008, 09h32
befalimpertinent

Si je te demandais le code de la recopie et de l'affectation c'est que le type d'erreur que tu as peut s'expliquer par une mauvaise gestion des pointeurs à cet endroit. ;)

Je m'explique :
Si ton objet possède un pointeur vers un autre objet et que lors d'une copie tu te contentes d'affecter membres à membres, tu va faire pointer deux objets vers la même case mémoire.
Si plus loin un de tes deux objets est détruit et que dans ton destructeur il y a un delete sur le pointeur, cela va faire pointer le membre de ton deuxième objet ... dans le vide. ;)
Enfin bref je commencerai par vérifier recopie, affectation et destructeur à ce niveau.
Si rien ne parait suspect il faudra peut être te tourner vers des outils qui analysent les problèmes mémoires d'un programme (purify, valgrind, ...). Mais personnellement je n'en n'ai jamais utiliser.

Bon courage :D
11/01/2008, 18h22
DEVfan

OK.

Dans mon code, à ce niveau, je n'utilise pas de pointeur, si ce n'est ...this. Je m'appuie fortement sur la stl. D'ailleurs à ce sujet, peut-on me confirmer que les contenaires font bien appelent aux delete des classes contenus... donc vide bien proprement! Et aussi, doit-on faire clear() ou bien les conteneurs sont-ils proprement vidé?

Encore une idée, est-ce que le pb pourrait venir des const ... la recopie dans mon cas fait appel à du const mais ce peut-il qu'un objet soit transmis en non const et donc face du par défaut?

Merci.
11/01/2008, 20h02
Pacorabanix

Citation:

Envoyé par DEVfan

OK.

Dans mon code, à ce niveau, je n'utilise pas de pointeur, si ce n'est ...this. Je m'appuie fortement sur la stl. D'ailleurs à ce sujet, peut-on me confirmer que les contenaires font bien appelent aux delete des classes contenus... donc vide bien proprement! Et aussi, doit-on faire clear() ou bien les conteneurs sont-ils proprement vidé?

les conteneurs ne font en aucun cas appel à des delete. On peut créer des conteneurs de variables non-pointeurs, donc faire un "delete automatique" n'aurait pas de sens. Tu dois faire delete pour chaque pointeur vers ta classe que tu as inséré dans ton conteneur toi-même. De plus si tu fais delete sur tes pointeurs, les variables pointeurs ne disparaissent pas (elles pointent juste vers une zone désallouée) donc tu dois les supprimer toi même de ton conteneur. (chaque conteneur à une méthode adéquate, clear() par exemple pour tout supprimer)

Citation:

Encore une idée, est-ce que le pb pourrait venir des const ... la recopie dans mon cas fait appel à du const mais ce peut-il qu'un objet soit transmis en non const et donc face du par défaut?

Merci.

Le const est surtout là pour éviter au programmeur de faire des erreurs, justement en modifiant par hasard un truc qu'il n'aurait pas du.Cela indique au compilateur d'interdire toute modification de la variable, ou appel de fonction qui n'utilise pas cet argument en const. C'est donc plutot une bonne chose de le mettre ,ça évitera une partie des erreurs possibles.

Maintenant, si lors du constructeur de recopie le compilateur accepte le transfert d'un simple pointeur (donc modifiable), il devrait au moins afficher un warning il me semble.
11/01/2008, 23h22
DEVfan

Ah... ça peut expliquer des choses!! Mais c'est contraire à la logique, faire appel à delete sur chaque objet du conteneur puis faire clear()! J'avais cru lire le contraire ailleurs!
Et vu le nb d'objet de cette classe que j'ai créé avant... ça m'étonne.

Pour le warning, ok et de ce côté, aucun.

EDIT : en fait, même si mon destructeur élimine terme à terme bêtement, ça devrait marcher... cette classe ne comporte que des éléments simples
...comment un pb de mémoire pourrait donc émerger!?:koi:

EDIT2 : ...j'ai prolongé le raisonnement... si le conteneur ne peut pas faire de destructeur, il ne devrait pas pouvoir faire de constructeur par défaut aussi.... et bien c'est presque vrai dans mon cas... j'ai juste 1 cas où c'est pas vrai. A part ce cas donc, je créé des iterateur null sauf si j'initialise le conteneur

...Je viens de me rendre compte que j'utilisais un peu rapidement conteneur jusque là... ils s'agissaient en fait des iterateurs du conteneur : Le conteneur a une adresse mais les iterateurs (comme spécifié en nom dans le premier post ...first, finish et end ... sont à NULL)

EDIT3 : ...ça devient grave docteur, le compilateur ne veut plus que je fasse un iterator1<iterator2 ... c'est quoi ces quacks chelu? On m'a verolé Eclipse?!

Citation:
Code:

1 2 3 4 5 6 7 8 //ressouder for(vector<GLignage>::iterator ite=recup_temp.begin(); ite<recup_temp.end();++ite) { if(!((*ite).soudure(recup_tmp))) {// le pb est là! recup_tmp.push_back(*recup_temp.begin()); } }
Donc je recopie simplement recup_temp dans recup_tmp...
[EDIT]: Oups, elle est où la suite...... Voir le prochain message....

Citation:
Code:

1 2 3 4 5 6 7 8 //ressouder for(vector<GLignage>::iterator ite=recup_temp.begin(); ite<recup_temp.end();++ite) { if(!((*ite).soudure(recup_tmp))) {// le pb est là! recup_tmp.push_back(*recup_temp.begin()); } }
Donc je recopie simplement recup_temp dans recup_tmp...
Non, tu ajoutes le premier élément de recup_temp à recup_tmp. Et, si dans ta fonction soudure, tu modifie ton vecteur, les itérateurs deviennent invalides.

12/01/2008, 14h28
DEVfan

Dans soudure, je modifie effectivement le vecteur (sinon pourquoi le passer)... et en quoi ça invalide les iterateurs??? A quoi sert donc une classe si on ne peut pas y toucher!! (rq : passé en référence)

Pour le détail ... oui en effet je recopie que le premier... mais une partie est masqué dans soudure justement.
13/01/2008, 20h46
Albenejean

Quand la structure du vecteur est modifié, les itérateurs sont invalides.
Si tu supprime un élément, si tu en ajoutes, il peut y avoir une réalocation en mémoire. Donc les itérateurs que tu as utilisé précédemment pointent... là où il ne devraient pas.
Tu n'y peux rien, c'est comme ça...
13/01/2008, 23h36
DEVfan

oui effectivement. Mais ce qui me surprends le plus, c'est les pointeurs vers NULL. Parce que du coup faire un push_back... il sait plkus le faire!! :

Vecteur d'adresse ..bidule (non NULL)
et iterateur tous à NULL
=> pb!!!
14/01/2008, 09h15
yan

Citation:

Envoyé par DEVfan

Dans soudure, je modifie effectivement le vecteur (sinon pourquoi le passer)... et en quoi ça invalide les iterateurs??? A quoi sert donc une classe si on ne peut pas y toucher!! (rq : passé en référence)

Pour le détail ... oui en effet je recopie que le premier... mais une partie est masqué dans soudure justement.

Bonjour que fait tu dans soudure sur le vector??
14/01/2008, 16h44
DEVfan

Justement, je suis en train de réexaminer cette question parce qu'il arrive que je manipule this (enfin son contenu) et qu'à la fois il soit dans le vecteur modifié et modifiable... réponse à ça dans un Edit

EDIT : parcours du vecteur et si this vérifie une certaine propriété avec un objet du vecteur... fusion d'une copie de this avec l'objet du vecteur.
Donc le vecteur en soit n'est pas modifié mais son contenu oui!
14/01/2008, 16h53
yan

Citation:

Envoyé par DEVfan

Justement, je suis en train de réexaminer cette question parce qu'il arrive que je manipule this (enfin son contenu) et qu'à la fois il soit dans le vecteur modifié et modifiable... réponse à ça dans un Edit

En faite c'etait pour te dire que ressouder devrait du coup retourner un iterateur valid comme insert ou erase
http://www.cplusplus.com/reference/s...tor/erase.html
Mais ça aurai été plus simple en voyant ta fonction :aie:
14/01/2008, 17h26
DEVfan

Merci pour le lien, je le perds toujours celui-là!

ça me rassure pour l'appel automatique du destructeur :

Citation:

This effectively reduces the vector size by the number of elements removed, calling each element's destructor before.

Et si ça le fait pour erase, ça doit bien le faire pour toute destruction!!!:lol:

Bon par contre, ça change rien au pb. Dans quel cas le vecteur peut-il mettre tous ses conteneurs sur NULL et cela invalide quels process de la stl associé!!?:scarymov:
14/01/2008, 17h30
yan

Citation:

Envoyé par DEVfan

Merci pour le lien, je le perds toujours celui-là!

ça me rassure pour l'appel automatique du destructeur :

Et si ça le fait pour erase, ça doit bien le faire pour toute destruction!!!:lol:

Oui mais si ses un vecteur de pointeur. C'est le pointeur qui est detruit, pas ce qui est pointé. C'est pas la même chose

Citation:

Envoyé par DEVfan

Bon par contre, ça change rien au pb. Dans quel cas le vecteur peut-il mettre tous ses conteneurs sur NULL et cela invalide quels process de la stl associé!!?:scarymov:

J'ai pas bien compris... Comment sait tu que ton conteneur contiens que des NULL???
Tu developpe avec quoi?
14/01/2008, 22h31
DEVfan

Ce sont des vecteurs d'une classe C... pas de vecteur de pointeur

Ensuite, je développe avec Eclipse et les options standard pour le C++. Lors du debug, on peut suivre des variables et en particulier les iterateurs début, fin et fin de stockage ... et ceux là sont dans ce cas précis à NULL (0x00000000). Et ça me pose un problème!! Il veut pas le remplir! (avec=truc ou avec push_back ou insert, etc.!!!)
14/01/2008, 22h40
yan

Ça ressemble a quoi l'interface de la fonction soudure?
Et tu sur de ton interprétation??
Genre _M_start, _M_finish, _M_end_of_storage vaut zero car
les structures GLignage associées sont composé que de zéro en memoire?
15/01/2008, 01h10
DEVfan

2 pièce(s) jointe(s)

Oui, c'est possible... je met en pj le lieu du pb d'un point de vue graphique

Avt l'appel de la fonction, vecteur normal mais de taille nulle et dedans, vecteur recopié "à NULL".

RQ : la fonction s'appelle en réalité soude_jointure mais j'ai racourci en soudure ... et j'en changerais sans doute encore une fois le code fini;) Mais l'idée est la même.
15/01/2008, 11h14
yan

tu pourrais mettre ton code soudure jointure?
par ce que la j'ai plus d'idée

oui ... mais elle fait rien pour l'instant :

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
 
bool GLignage::soude_jointure(vector<GLignage>& amas)
  {
//l'amas est déjà invalide ici... iterateurs sur NULL
   if(amas.size()==0)
     {
	  amas.push_back(*this);
	  return 1;
     }
 
   bool stop=false;
   int compteur=0;
 
   while(!stop)
     {
	  stop=true;
	  for(vector<GLignage>::iterator ite=amas.begin();ite<=amas.end();++ite)
        {
		 if(joint(*ite))
		   {
			compteur++;
			//break; j'optimiserais plus tard
		   }
        }
     }//fin du while
 
   //risque de jointure en cascade : 
   /*if(compteur>1)
     {
 
     }*/
   //todo
   return (compteur>0);
  }
/////

RQ : joint modifie l'objet passé en paramètre dans certaines conditions... mais même en commentaire, le pb reste (logique!)

16/01/2008, 21h18
DEVfan

J'ai refait qq tests ... et ce n'est pas le seul cas où les vector<GLignage> sont créés à NULL. J'ai alors relu la doc STL sur les vector et il semblerait que ce soit logique d'après cette phrase :

Citation:

explicit vector ( const Allocator& = Allocator() );
Default constructor: constructs an empty vector, with no content and a size of zero.

Mais parfois, ce n'est pas à NULL... donc mystère.

Le pb est donc ailleurs...

EDIT : nouvel cause en cours...
passer une référence sur un vector dans une méthode (ou un fonction) puis modifier le contenu du vector... qu'obtient-on à la sortie... et bien parfois la même chose qu'au départ!!! Personnellement, je trouve que ça défie mes connaissances du C++!!!

Normalement, fct(a, &a, *a) permet de laisser a, &a et a intact mais permet de modifier rien, a et *a. (respectivement)
16/01/2008, 21h25
yan

Citation:

Envoyé par DEVfan

J'ai refait qq tests ... et ce n'est pas le seul cas où les vector<GLignage> sont créés à NULL. J'ai alors relu la doc STL sur les vector et il semblerait que ce soit logique d'après cette phrase :

Mais parfois, ce n'est pas à NULL... donc mystère.

Le pb est donc ailleurs...

???
ce n'est pas le même problème...

Question ton code plante?? c'est bien ça? ou c'est juste que tu voie des 0 et donc tu considère que ton code va planter?

Sinon,a mon avis tu fait une erreur mémoire avant. D'où tes 0 qui apparaisse bizarrement.
Peut tu mettre toute la fonction où tu appel soude_jointure?
16/01/2008, 23h11
DEVfan

...en effet et je viens d'en trouver la cause.

Alors premièrement, je sais pas trop pourquoi ça plante plus... devais y avoir un pb de mémoire qq part... je sens que je retomberais dessus un jour :?

Et deuxième pb... il manquait le symbole de référence:boulet: ... et le gestionnaire eclipse avait librement inventé des méthodes sans, avec et pour pointeur!!! Merci Eclipse!:furieux:
16/01/2008, 23h37
yan

Citation:

Envoyé par DEVfan

...en effet et je viens d'en trouver la cause.

Alors premièrement, je sais pas trop pourquoi ça plante plus... devais y avoir un pb de mémoire qq part... je sens que je retomberais dessus un jour :?

Et deuxième pb... il manquait le symbole de référence:boulet: ... et le gestionnaire eclipse avait librement inventé des méthodes sans, avec et pour pointeur!!! Merci Eclipse!:furieux:

lol

Fuseau horaire GMT +2. Il est actuellement 12h12.