Implémentation STL de MS VC++2005

Bonjour,
Je suis passé de VS2003 à VS2005 et j'ai noté le problème suivant : il semble que de nombreuses choses ont changé dans l'implémentation de la STL.
Depuis la nouvelle version, il n'est plus possible de comparer (pour l'égalité) des itérateurs de liste correspondant à des containers différents.
En effet :

Code:

---

1 2 3 4 5 6 7 8 9 10

#if _HAS_ITERATOR_DEBUGGING void _Compat(const _Myt_iter& _Right) const { // test for compatible iterator pair if (this->_Mycont == 0 || this->_Mycont != _Right._Mycont) { _DEBUG_ERROR("list iterators incompatible"); _SCL_SECURE_TRAITS_INVALID_ARGUMENT; } }

---

En effet, il vérifie

Code:

---

1 2	this->_Mycont != _Right._Mycont

---

Je cherche une façon de contourner celà facilement.

La raison est que j'ai une classe type conteneur , qui utilise la liste de la stl. (c'est un pool d'objet avec une stratégie d'allocation.)
Les iterateurs de ce conteneur sont implémentés à partir d'un itérateur de liste. Je reproduit le concepte de "pointeur NULL" avec un

Code:

---

const static iterator DUMMY

---

(défini dans la class d'itérateur, idem pour le const_iterator). Ces valeurs statiques sont initialisées à partir d'une instance statique vide du conteneur avec begin().
Avec cette nouvelle implémentation de la stl, je ne peux plus comparer mes iterator avec iterator::DUMMY ou mes const_iterator avec const_iterator::DUMMY .

Une idée ?
S.

La première option qui me vient à l'esprit, c'est ceci:

Code:

---

1 2	//En tête de source, avant les includes #define _HAS_ITERATOR_DEBUGGING 0

---

Et si tu les initialise avec le constructeur pas défaut de l'itérateur ?

Non, ils sont statiques et donc initialisés indépendamment.
S.

Je n'ai pas compris ta réponse. Si ils sont initialisés avec le constructeur par défaut des itérateurs, sont-ils comparables sans problème avec des itérateurs venant de n'importe où (peut-être ce cas spécial est-il géré par la STL Microsoft)?

Les itérator et const_iterator "DUMMY" sont des variables membres const et static des classes iterator et const_iterator, donc initialisées indépendamment de tout constructeur car ils sont indépendants de l'instance de la classe.
Ils sont initialisés avant même l'exécution de main()
Le problème que j'ai avec la STL implémentée par MS, c'est qu'ils n'autorisent pas la comparaison par "==" et "!=" d'itérateurs de liste de même type si ils correspondent à des listes différentes. En effet, dans leur implémentation, l'itérateur possède un pointeur vers son container et si ces conteneurs sont différents, la comparaison lance une exception.
Il semble que ce probleme soit résolu en définissant due variables d'environnement à 0. (Je poste la solution tout à l'heure.) Ils semble que ce type d'implémentation soit standard.
en effet :
http://std.dkuug.dk/jtc1/sc22/wg21/d...1997/N1075.pdf voir le début de la page 2, écrite par le grand gourou du c++ .
Je vais donc devoir faire une implémentation qui respecte ce cas sans passer par une solution sale type variable d'environnement.
S.

Les #define à faire sont donc
#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0
S.

Qu'est-ce que c'est que cette histoire de variable d'environnement ?
Je n'ai parlé que de defines, moi...

Citation:

---

Envoyé par nikopol82

Les itérator et const_iterator "DUMMY" sont des variables membres const et static des classes iterator et const_iterator, donc initialisées indépendamment de tout constructeur car ils sont indépendants de l'instance de la classe.
Ils sont initialisés avant même l'exécution de main()

---

Oui, j'ai bien compris qu'il s'agit de variables statiques, il n'empêche qu'elles sont bel et bien construites à l'aide d'un constructeur.

Ici, tu les construis de façon à ce qu'elles correspondent au début d'une liste bidon, je te proposais de les construire à l'aide du constructeur par défaut de la classe d'itérateur, qui construit un itérateur non valide.

Mon idée est que si la comparaison d'itérateurs de deux listes différentes pose une erreur, ce qui est normal, prévu et sain, peut-être que la comparaison d'un itérateur normal avec un itérateur construit par défaut (qui est un peu une valeur spéciale) est un cas prévu pour ne pas poser d'erreur (et retourner faux, bien entendu).

[/QUOTE]

Désolé, il ne s'agit pas de Variables d'environnement évidemment.
C'est bien des macros.
Je corrige mon message avec la solution.
ce qu'il faut faire avant les include est
#define _SECURE_SCL 0
#define _HAS_ITERATOR_DEBUGGING 0
Sorry pour le lapsus

Pourquoi est-ce que tu as besoin de comparer des itérateurs de listes différentes ???

Parce que ses itérateurs "dummy" ne proviennent d'aucune liste en particulier.

Citation:

---

Depuis la nouvelle version, il n'est plus possible de comparer (pour l'égalité) des itérateurs de liste correspondant à des containers différents.

---

Et c'est tout à fait normal.
Fixe ton code.

Pour l'instant, je laisse vivre le code avec les #define, mais c'est sur que la solution n'est pas très propre.
La solution de JolyLoic est plus propre en terme de conception (un iterateur bidon initialisé par le constructeur par défaut) contrairement au membre statique. (Désolé JolyLoic, je n'avais pas compris ta question au début.)
Seulement cette solution augmente la taille mémoire des iterateurs, (eh oui, il y a un itérateur bidon en plus dans un iterator.)
La solution propre me semble être de garder cette idée cette idée de membre statique, mais de ne pas utiliser l'égalité des itérateurs de liste pour tester l'égalité de mes itérateurs. Je ne sais pas encore vraiment comment contourner celà proprement... Si quelqu'un a une idée ;)
En tous cas merci pour ces réponses et d'avoir lu et compris le problème. Je pensais vraiment qu'il était standard de comparer des iterateurs de listes différentes, ie, "==" renvoie true si les iterator sont égaux, false sinon...
S.

Le problème majeur, c'est que l'itérateur retourné par end() n'est pas forcément le même d'une instance à l'autre d'une collection...

Typiquement, par exemple, pour un std::vector< T > qui utiliserait directement un T* comme itérateur...

Oui, c'est sur que si end() était toujours le même itérateur ça serait la solution. Plus besoin de dummy...