Salut,
 
J'ai des librairies C++ qui avaient été faite sous Linux et compilées à GCC.
J'ai enfin réussi à les compiler sous VisualStudio mais lors de l'exécution d'un des tests, j'ai l'erreur suivante : vector iterators incompatible.
http://i1007.photobucket.com/album [...] /error.png
 
Je n'ai absolument aucune idée du problème. J'avoue que je reste perplexe quant aux résultats de mes recherches sur le web pour trouver une explication.
 
Si je regarde un peu dans le code, je trouve des choses comme ça :

 
Avez-vous une idée de ce qui ne plait pas à VS ?
Sous Linux/GCC 4.3, mon test passe sans problème.
 
Si qq'un a une idée, une piste ou une explication, je suis preneur ...
 
Merci de votre aide.

Le probleme n'est pas dans ce que tu montres.  Tu compares vraisemblablement deux iterateurs sur des conteneurs differents, ou peut-etre avec un iterateur invalide.

ok.
 
 

Serait-ce un problème de template ? pourquoi alors mon test passe sous gcc ? y a t il une utilisation différente des templates sous VS ?
 

Ca voudrait dire quoi un itérateur invalide ?
Des manipulations sur le vecteur qui ne sont pas permises ?
 
Merci de votre aide

 
Tu ne montres pas de template...
 

 
Comportement indefini, ca fait n'importe quoi.  Y compris ce a quoi tu t'attends.  Est-ce que tu as essaye avec la version de la lib de gcc qui fait des verifs?
 

 
p.e. un iterateur qui n'a pas ete initialise, ou bien dont le conteneur a ete detruit, ou l'element qui est "pointe" par l'iterateur a ete detruit...
 

Je parle de la classe vector de la lib STL :

Je me dis que j'ai peut-être un problème avec ca ...
 

De quelle version de gcc parles-tu ?  
Pour info, les librairies que j'utilise existent et sont utilisées depuis plusieurs années sous Linux/gcc. Je pars du principe que c'est ok sous cet environnement là.
Mais si je peux faire un test pour en assurer grace à ta "version de gcc qui fait des vérifs", ce se tente... car faut bien que je trouve le bug ;-)
 

Je continue l'enquête pour essayer de trouver le problemem mais c'est pas gagné    
 
Je reste connecté au fofo, si vous avez des idées ...  
 
merci de ton aide "Un programmeur" car y a pas foule aujourd'hui ....

Et tu ne peux pas nous donner la portion de code où ça plante ?

Je passe en debug et dès que j'ai ciblé précisemment les lignes qui posent problème, je post.
Mais j'avoue que je suis pas super efficace, c'est pas mon code, je connais pas les libs ... bref je débute avec ces librairies...
 
Je reviens asap avec du code a vous mettre sous la dent.

Commence par te dire qu'il y a un probleme dans ton code.  C'est beaucoup plus vraisemblable.
 

 
http://gcc.gnu.org/onlinedocs/libs [...] _mode.html

 
ok merci. Bien noté.
Je vais tenter le mode debug dont tu parles.
 
merci

salut
Après une courte pause sur d'autres projets tout autant réjouissant, je reviens sur mon problème.
 
Je viens apporter un complément d'information qui j'espère vous donnera des idées sur  le problème que je rencontre.
 
Bon, j'ai toujours l'erreur "vector iterators incompatible". J'ai localisé le plantage.
 
Il y a dans le code un test != entre 2 objets de classe std::_Vector_const_iterator<Arc,std::allocator<Arc> >, où Arc est une classe de la librairie.
Ca plante donc sur l'opérateur != de _Vector_const_iterator (fichier c:\Program Files\Microsoft Visual Studio 9.0\VC\include\vector)
Le test est :

 
Un watch sur crossing me donne:

 
Un watch sur toBeTested me donne:

 
Dans la classe _Vector_const_iterator:

 
Un watch sur *this:

 
Un watch sur _Right:

 
Je comprends toujours pas ce qui le dérange
Quelqu'un aurait-il une idée ????
 
En attendant, je repasse sous Linux, suivre les conseils de Un Programmeur et voir si je trouve qq  chose de louche...
 
Please, help me !!!
Merci de votre aide

c'est fou ... autant de posts et toujours pas un bout de code à regarder ... Poste le corps de la fonction où ton erreur arrive, pas juste une ligne de comparaison avec des variables qui viennent d'on ne sait où

Milles excuses ... voici du code, celui de la fonction appelante :

 
Au passage, il s'agit d'une bibliothèque gratuite du CNES, nommée Marmottes: http://logiciels.cnes.fr/MARMOTTES/fr/logiciel.htm

dans le cas où boundary_ est un vecteur vide, je ne sais pas ce qui se passe, ce ne serait pas ce cas-là que tu rencontres ?

Non, je ne pense pas puisque toBeTested peut être récupéré (et non vide) :

end() renvoie un iterateur non-valide (c'est son comportement), donc non.

là, comme ca, je ne crois pas voir d'erreur flagrante, donc, mise à part le fait que tu assumes que boundary_ contient au moins un élément.
 
Attention aux effets de bord peut-être ? Est-ce que modifier ptrArc (intersection, affectation d'une nouvelle valeur) ne va pas invalider tes itérateurs ?

 
C'est exactement ce sur quoi j'enquete car j'ai lu 2,3 postes (http://objectmix.com/c/738852-ques [...] tor-t.html, http://objectmix.com/c/708702-quer [...] ector.html) qui me font penser qu'un truc doit changer  dans le vecteur qui fout l'itérateur en l'air ....
 
Mais que c'est hard à trouver ....

 
Tu récupère l'itérateur de fin de la première liste contenue dans boundary_ or crossing peut appartenir a n'importe laquelle de ces listes.
Comparer un itérateur d'une liste avec un itérateur d'une autre liste est un comportement indéfini.

Pourrais-tu détailler un peu ta réponse stp car je vois pas bien le "Comparer un itérateur d'une liste avec un itérateur d'une autre liste est un comportement indéfini." ?
 
Et une autre question, si ce type de comparaison n'est pas autorisé en C++, pourquoi les tests passent avec succès sous GCC ?
 
 
Merci

Parce qu'un comportement indefini ca peut etre n'importe quoi.  Y compris ce a quoi tu t'attends du moins jusqu'a la demo devant le client.
 
VC++ a un mode de validation qui detecte le probleme et te l'indique.  g++ a un mode de validation capable de detecter ce genre de probleme mais tu ne l'utilises pas.

ok donc j'imagine que désactiver SECURE_SCL et _HAS_ITERATOR_DEBUGGING pour faire passer mon test est une très mauvaise idée ....      
 
J'ai fait le test sous Linux/GCC avec l'option _GLIBCXX_DEBUG ... et devinez ...

 
Donc y a bien un petit problème ...

Je vais détailler un peu.
 
Par exemple avec le cas des vectors, on pourrait très bien utiliser pour l'itérateur de fin un pointeur pointant après le dernier élément d'un tableau utilisé en interne pour stocker les éléments.
Les deux vecteurs n'ayant pas les mêmes tableaux internent, les pointeurs ne peuvent donc pas être comparés.
 
On pourrait tout aussi bien stocker dans l'itérateur une valeur NULL en arrivant à la fin d'un tableau, ce qui rendrait l'itérateur de fin indépendant du vector.
 
Ce ne sont que des exemples simplifiés d'implémentation mais j'espère que tu comprendras un peu mieux ce que peut être un comportement indéfini.

ouep, je commence à voir le blème... un doc intéressant (enfin pour moi, qui m'a permis de me rendre compte du problème :http://www.osl.iu.edu/publications [...] GrSc02.pdf)
 
(Edit: lien précédent corrumpu)