Warum Iteratoren anstelle von Array-Indizes verwenden?

Nehmen Sie die folgenden zwei Codezeilen:

for (int i = 0; i < some_vector.size(); i++)
{
    //do stuff
}

Und das:

for (some_iterator = some_vector.begin(); some_iterator != some_vector.end();
    some_iterator++)
{
    //do stuff
}

Mir wurde gesagt, dass der zweite Weg bevorzugt wird. Warum genau ist das so?

Die erste Form ist nur effizient, wenn vector.size() eine schnelle Operation ist. Das gilt für Vektoren, aber beispielsweise nicht für Listen. Und was hast du vor, innerhalb des Körpers der Schleife zu tun? Wenn Sie vorhaben, auf die Elemente wie in zuzugreifen

T elem = some_vector[i];

dann machen Sie die Annahme, dass der Behälter hat operator[](std::size_t) definiert. Auch dies gilt für Vektoren, aber nicht für andere Container.

Der Einsatz von Iteratoren bringt Sie näher heran Containerunabhängigkeit. Sie machen keine Annahmen über die Fähigkeit zum wahlfreien Zugriff oder schnell size() Operation, nur dass der Container Iteratorfähigkeiten hat.

Sie könnten Ihren Code weiter verbessern, indem Sie Standardalgorithmen verwenden. Je nachdem, was Sie erreichen möchten, können Sie sich für die Verwendung entscheiden std::for_each(), std::transform() und so weiter. Indem Sie anstelle einer expliziten Schleife einen Standardalgorithmus verwenden, vermeiden Sie es, das Rad neu zu erfinden. Ihr Code ist wahrscheinlich effizienter (vorausgesetzt, der richtige Algorithmus wird gewählt), korrekt und wiederverwendbar.

Es ist Teil des modernen C++-Indoktrinationsprozesses. Iteratoren sind die einzige Möglichkeit, die meisten Container zu iterieren, also verwenden Sie sie auch mit Vektoren, nur um sich in die richtige Denkweise zu versetzen. Im Ernst, das ist der einzige Grund, warum ich es mache – ich glaube nicht, dass ich jemals einen Vektor durch eine andere Art von Container ersetzt habe.

Wow, das wird nach drei Wochen immer noch heruntergestimmt. Ich denke, es zahlt sich nicht aus, ein wenig ironisch zu sein.

Ich denke, der Array-Index ist besser lesbar. Es entspricht der Syntax, die in anderen Sprachen verwendet wird, und der Syntax, die für altmodische C-Arrays verwendet wird. Es ist auch weniger ausführlich. Effizienz sollte eine Wäsche sein, wenn Ihr Compiler gut ist, und es gibt sowieso kaum Fälle, in denen es darauf ankommt.

Trotzdem verwende ich immer noch häufig Iteratoren mit Vektoren. Ich glaube, dass der Iterator ein wichtiges Konzept ist, also fördere ich ihn, wann immer ich kann.

weil Sie Ihren Code nicht an die bestimmte Implementierung der some_vector-Liste binden. Wenn Sie Array-Indizes verwenden, muss es sich um eine Art Array handeln. Wenn Sie Iteratoren verwenden, können Sie diesen Code für jede Listenimplementierung verwenden.

Stellen Sie sich vor, some_vector wird mit einer verketteten Liste implementiert. Dann erfordert das Anfordern eines Elements an der i-ten Stelle, dass i Operationen durchgeführt werden, um die Liste von Knoten zu durchlaufen. Wenn Sie jetzt einen Iterator verwenden, wird er sich im Allgemeinen nach besten Kräften bemühen, so effizient wie möglich zu sein (im Fall einer verknüpften Liste behält er einen Zeiger auf den aktuellen Knoten bei und setzt ihn bei jeder Iteration fort, was nur eine erfordert Einzelbetrieb).

Es bietet also zwei Dinge:

• Abstraktion der Verwendung: Sie möchten nur einige Elemente iterieren, es ist Ihnen egal, wie Sie dies tun
• Leistung

Ich werde hier der Anwalt des Teufels sein und keine Iteratoren empfehlen. Der Hauptgrund dafür ist, dass der gesamte Quellcode, an dem ich gearbeitet habe, von der Entwicklung von Desktop-Anwendungen bis hin zur Spieleentwicklung, weder Iteratoren erforderlich ist. Die ganze Zeit waren sie nicht erforderlich, und zweitens machen die versteckten Annahmen und Code-Chaos und Debugging-Albträume, die Sie mit Iteratoren bekommen, sie zu einem Paradebeispiel dafür, sie nicht in Anwendungen zu verwenden, die Geschwindigkeit erfordern.

Sogar aus Wartungsgründen sind sie ein Chaos. Es liegt nicht an ihnen, sondern an all dem Aliasing, das hinter den Kulissen passiert. Woher weiß ich, dass Sie keine eigene virtuelle Vektor- oder Array-Liste implementiert haben, die etwas völlig anderes als die Standards macht? Weiß ich, welcher Typ gerade jetzt zur Laufzeit ist? Haben Sie einen Operator überladen, hatte ich keine Zeit, Ihren gesamten Quellcode zu überprüfen. Verdammt, weiß ich überhaupt, welche Version der STL Sie verwenden?

Das nächste Problem, das Sie mit Iteratoren haben, ist die undichte Abstraktion, obwohl es zahlreiche Websites gibt, die dies ausführlich mit ihnen diskutieren.

Sorry, ich habe und habe noch keinen Sinn in Iteratoren gesehen. Wenn sie die Liste oder den Vektor von Ihnen abstrahieren, obwohl Sie eigentlich bereits wissen sollten, mit welchem ​​Vektor oder welcher Liste Sie es zu tun haben, wenn Sie dies nicht tun, werden Sie sich nur auf einige großartige Debugging-Sitzungen in der Zukunft einstellen.

Möglicherweise möchten Sie einen Iterator verwenden, wenn Sie dem Vektor Elemente hinzufügen/entfernen, während Sie darüber iterieren.

some_iterator = some_vector.begin(); 
while (some_iterator != some_vector.end())
{
    if (/* some condition */)
    {
        some_iterator = some_vector.erase(some_iterator);
        // some_iterator now positioned at the element after the deleted element
    }
    else
    {
        if (/* some other condition */)
        {
            some_iterator = some_vector.insert(some_iterator, some_new_value);
            // some_iterator now positioned at new element
        }
        ++some_iterator;
    }
}

Wenn Sie Indizes verwenden, müssten Sie Elemente im Array nach oben/unten mischen, um die Einfügungen und Löschungen zu verarbeiten.

Trennung von Bedenken

Es ist sehr schön, den Iterationscode von dem „Kern“ der Schleife zu trennen. Es ist fast eine Designentscheidung.

In der Tat bindet Sie die Iteration nach Index an die Implementierung des Containers. Wenn Sie den Container nach einem Anfangs- und End-Iterator fragen, wird der Schleifencode für die Verwendung mit anderen Containertypen aktiviert.

Auch in der std::for_each Weg, du Sagen Sie der Sammlung, was sie tun soll, anstatt zu fragen es etwas über seine Interna

Der 0x-Standard wird Closures einführen, die diesen Ansatz viel einfacher zu handhaben machen – sehen Sie sich zB die Ausdruckskraft von Ruby an [1..6].each { |i| print i; }…

Leistung

Aber vielleicht ist ein viel übersehenes Problem die Verwendung von for_each Ansatz bietet die Möglichkeit, die Iteration parallelisieren zu lassen – die Intel-Threading-Blöcke kann den Codeblock über die Anzahl der Prozessoren im System verteilen!

Hinweis: Nach der Entdeckung der algorithms Bibliothek und vor allem foreach, habe ich zwei oder drei Monate damit verbracht, lächerlich kleine Hilfsoperatorstrukturen zu schreiben, die Ihre Entwicklerkollegen verrückt machen werden. Nach dieser Zeit bin ich zu einem pragmatischen Ansatz zurückgekehrt – kleine Schleifenkörper verdienen nichts foreach nicht mehr 🙂

Eine unverzichtbare Referenz zu Iteratoren ist das Buch “Erweiterte STL”.

Die GoF haben am Ende des Iterator-Musters einen winzig kleinen Absatz, der über diese Art der Iteration spricht; es wird ein “interner Iterator” genannt. Guck mal Hierzu.