Pourquoi "!=" utilisé avec les itérateurs?

Question

Je suis habitué à l'écriture de boucles comme ceci:

for (std::size_t Index = 0; Index < Foo.Size(); Index++)
{
    // Do stuff with Foo[Index].
}

Mais quand je vois itérateur boucles dans le code d'autres, ils ressemblent à ceci:

for (Bar::Iterator Iterator = Foo.Begin(); Iterator != Foo.End(); Foo++)
{
    // Do stuff with *Iterator.
}

Je trouve l' Iterator != Foo.End() à offputting. Il peut aussi être dangereux si Iterator est incrémenté par plus d'un.

Il semble plus "correct" pour utiliser Iterator < Foo.End(), mais je ne vois jamais que dans le code réel. Pourquoi pas?

Answer 1

Tous les itérateurs sont l'égalité comparables. Seulement accès aléatoire itérateurs sont comparables sur le plan relationnel. Entrée itérateurs, avant les itérateurs, et itérateurs bidirectionnels sont pas comparables sur le plan relationnel.

Ainsi, la comparaison à l'aide de != est plus générique et plus souple que la comparaison à l'aide de <.

---

Il existe différentes catégories d'itérateurs parce que pas toutes les gammes d'éléments ont les mêmes propriétés d'accès. Par exemple,

• si vous avez un itérateurs dans un tableau (une séquence contiguë d'éléments), il est trivial de manière relationnelle de les comparer; il vous suffit de comparer les indices du relevé d'éléments (ou les pointeurs pour eux, puisque les itérateurs probablement juste contiennent des pointeurs vers les éléments);

• si vous avez des itérateurs dans une liste, et vous voulez savoir si un itérateur est "moins que" un autre itérateur, vous avez à marcher dans les nœuds de la liste liée de l'un itérateur jusqu'à ce que vous atteignez l'autre itérateur ou vous atteignez la fin de la liste.

La règle est que toutes les opérations sur un itérateur doit avoir de la constante de temps de la complexité (ou, au minimum, sublinéaire temps de la complexité). Vous pouvez toujours effectuer une comparaison d'égalité dans la constante de temps puisque vous suffit de comparer si les itérateurs pointent vers le même objet. Donc, tous les itérateurs sont l'égalité comparables.

---

De plus, vous n'êtes pas autorisé à incrémenter un itérateur-delà de la fin de la gamme dans laquelle il pointe. Donc, si vous vous retrouvez dans un scénario où l' it != foo.end() ne pas faire la même chose que it < foo.end(), vous avez déjà un comportement indéfini parce que vous avez réitéré au-delà de la fin de la gamme.

La même chose est vraie pour les pointeurs dans un tableau: vous n'êtes pas autorisé à incrémenter un pointeur au-delà d'un passé la fin du tableau; un programme qui permet de faire présente un comportement indéfini. (La même chose est évidemment pas vrai pour les indices, puisque les indices sont tout entiers.)

Certaines implémentations de la Bibliothèque Standard (comme le Visual C++ de la Bibliothèque Standard de mise en œuvre) utile de débogage de code qui permettra de soulever une assertion lorsque vous faites quelque chose d'illégal avec un itérateur comme ça.

Answer 2

Réponse courte: Parce qu' Iterator n'est pas un nombre, c'est un objet.

Plus réponse: Il y a plus de collections de tableaux linéaires. Les arbres et les tables de hachage, par exemple, ne pas vraiment se prêter à des "cet indice est avant cette autre indice". Pour un arbre, deux indices qui vivent sur les branches distinctes, par exemple. Ou, tout deux indices dans une table de hachage -- ils n'ont pas d'ordre à tous, donc n'importe quel ordre vous imposer est arbitraire.

Vous n'avez pas à vous inquiéter au sujet de "manque" End(). Il est également pas un nombre, c'est un objet qui représente la fin de la collection. Il ne fait pas de sens d'avoir un itérateur qui passe devant elle, et en effet il ne peut pas.

Answer 3

bool solve(){
    map<int,int>::iterator a,b;
    return a<b;
}

Résultat:

error: no match for ‘operator<' dans ‘ < b'