Wieso Iteratoren statt Zeigern oder statt Indizes?

Artchi

"Sie entkoppeln Algorithmen von den Containern, so dass diese typenunabhängig formuliert werden können."

Quelle: http://de.wikipedia.org/wiki/C%2B%2B-Standardbibliothek#Iteratoren

Eisflamme

Artchi schrieb:

"Sie entkoppeln Algorithmen von den Containern, so dass diese typenunabhängig formuliert werden können."

Quelle: http://de.wikipedia.org/wiki/C%2B%2B-Standardbibliothek#Iteratoren

Trifft auch auf Indizes zu...

Tachyon:
Wenn operator++ überladen werden kann, kann man auch so ein Mapping erstellen. Wie gesagt, das muss man natürlich auch tun. Es sei denn, da liegt ne verkettete Liste hinter... aber das ist ja alles schon hier besprochen.

Shade Of Mine

Eisflamme schrieb:

Trifft auch auf Indizes zu...

Nein. Weil nicht alle Datenstrukturen Random Access bieten.

Für Datenstrukturen wo es einen sinvollen index gibt, sind indizes natürlich eine gute Lösung - aber viele Datenstrukturen bietet das einfach nicht. Es macht oft auch keinen Sinn - zB bei Streaming Algorithmen.
Weiters hat man kein Problem mit underflow/overflow bei iteratoren - bei indizes kann das ein Problem werden. Auch muss man bei indizes wissen wieviele Elemente man hat -> das weiss man aber auch nicht immer.

indizes sind nix anderes als random access iteratoren - iteratoren bieten aber mehr.

Weiters kann man iteratoren kapseln um zB backwards iteratoren zu bekommen. Dann auch zB insert iteratoren.

und und und - iteratoren sind ein abstraktes Konzept. Sie ermöglichen viele Sachen. indizes sind eine konkrete Implementierung.

PS:
"Es sei denn, da liegt ne verkettete Liste hinter"

Die meisten Datenstrukturen haben keinen Random Access. Nur sehr wenige bieten Random Access an und das zu einem hohen Preis.

Eisflamme

Nein. Weil nicht alle Datenstrukturen Random Access bieten.

Also das mit dem Random Access hab ich so langsam verstanden. Trotzdem könnte man - ich sage nicht, dass das eine gute Lösung ist - Indizes durch eine Mappingtabelle verwenden.

template<class T>
class queue
{
private:
// mapping in irgendeiner Form

public:
const T& get(std::size_t index) const {return *mapping[index];}
const T& operator[](std::size_t index) const {return get(index);}
// o.ä.
};

queue<int> oneQueue;
// Steck was rein
for(int std::size_t n = 0; n < oneQueue.size(); ++n)
    std::cout << oneQueue.get(n) << '\n';

Und nochmal. Wenn da verkettete Listen im Spiel sind, sehe ich ein, dass das blöd ist, weil man operator++ einfach implementieren kann. Falls das aber nicht vorliegt, benötigt man doch ohnehin irgend eine Art von Mapping, richtig?

Weiters hat man kein Problem mit underflow/overflow bei iteratoren - bei indizes kann das ein Problem werden. Auch muss man bei indizes wissen wieviele Elemente man hat -> das weiss man aber auch nicht immer.

[...]

Weiters kann man iteratoren kapseln um zB backwards iteratoren zu bekommen. Dann auch zB insert iteratoren.

Okay, das sehe ich ein.

Artchi

Die Reverse-Iteratoren sind auch cool, um einen Container rückwärts zu durchlaufen.
Bei Indizies muß ich dagegen meinen Algorithmus umbauen, z.B. aus i++ ein i-- machen und die End-Bedingung auch noch ändern.

Mit Iteratoren brauche ich bloß rbegin() anstatt begin() und rend() anstatt end() an den Algorithmus übergeben.

Indizies benutze ich trotzdem gerne. Sie sind ja nicht verhasst. Nur halt nicht so flexibel wie Iteratoren.

Bashar

Eisflamme schrieb:

Und nochmal. Wenn da verkettete Listen im Spiel sind, sehe ich ein, dass das blöd ist, weil man operator++ einfach implementieren kann. Falls das aber nicht vorliegt, benötigt man doch ohnehin irgend eine Art von Mapping, richtig?

Du tust immer so, als wäre die verkettete List ein Spezialfall. Der Spezialfall ist Random Access. Wie soll denn dieses Mapping z.B. bei einem Set oder einer Map aussehen? Von Input/Output-Iteratoren fang ich gar nicht erst an ...

Shade Of Mine

Eisflamme schrieb:

Also das mit dem Random Access hab ich so langsam verstanden. Trotzdem könnte man - ich sage nicht, dass das eine gute Lösung ist - Indizes durch eine Mappingtabelle verwenden.

Nicht immer. Und es kostet ja auch was.

Wenn du zB nicht weisst wieviele Elemente du hast, dann ist ein mapping garnichtmal so einfach. Gibt es zB das Element 27? Du weisst es zB erst wenn du Element 26 angelegt hast.

Indizes sind ein spezialfall: nämlich random access iteratoren.

Geh mal den anderen Weg: welchen Vorteil bieten indizes die du mit iteratoren nicht hast? Vielleicht verstehst du es so eher.

Bedenke: iteratoren funktionieren immer - egal welche struktur. indizes nur manchmal. weiters bieten indizes keinen vorteil gegenüber random access iteratoren.

Eisflamme

Vielleicht verstehst du es so eher.

Ok, bei allem Respekt, aber zum wiederholten Mal: Ich habe es verstanden, aber ich will das Thema einfach ein wenig erschöpfen. Nur weil es zwei Argumente für Iteratoren und nur eins dagegen gibt und das somit reichen würde, heißt das ja nicht, dass es nicht noch mehr Argumente gibt, die ich auch alle gerne hören würde. Ist das so schwer nachzuvollziehen? Bitte verwechselt meinen Perfektionismus nicht mit Dummheit, Sturheit, Uneinsichtigkeit oder gar Undankbarkeit.

Aber ich denke, das ist jetzt auch so gut wie erschöpft, Iteratoren bieten tatsächlich sehr viele Vorteile. Danke für die Geduld!

Du tust immer so, als wäre die verkettete List ein Spezialfall.

Ich bin einfach zu blöd zu schreiben, was ich eigentlich wissen will. Mir ging es darum, ob für etwaige andere Zugriffsmethoden als random access und verkettete Listen die Indexmethode nicht auch einfach umsetzbar sein könnte. Die Frage ist aber, ob es andere Zugriffsmethoden überhaupt gibt?

Tachyon

Eisflamme schrieb:

Wenn operator++ überladen werden kann, kann man auch so ein Mapping erstellen. Wie gesagt, das muss man natürlich auch tun. Es sei denn, da liegt ne verkettete Liste hinter... aber das ist ja alles schon hier besprochen.

Wie willst Du denn mappen? Auf welcher Grundlage? Die Reihenfolge der Einfügung von Elementen? Aufgrund der Sortierung? Aufgrund irgendeines Prädikates? Was ist sinnvoll, und was nicht? Und wer entscheidet das?
Bei assoziativen Containern hast Du bereits einen Index, welcher aber nicht numerisch sein muss. Was tust Du bei exotischen Index-Typen?

Bashar

Tachyon schrieb:

Wie willst Du denn mappen? Auf welcher Grundlage? Die Reihenfolge der Einfügung von Elementen? Aufgrund der Sortierung? Aufgrund irgendeines Prädikates? Was ist sinnvoll, und was nicht? Und wer entscheidet das?

Du argumentierst gerade gegen Iteratoren

Tachyon

Bashar schrieb:

Tachyon schrieb:

Wie willst Du denn mappen? Auf welcher Grundlage? Die Reihenfolge der Einfügung von Elementen? Aufgrund der Sortierung? Aufgrund irgendeines Prädikates? Was ist sinnvoll, und was nicht? Und wer entscheidet das?

Du argumentierst gerade gegen Iteratoren

Wieso das? Bei Iteratoren muss ich mich gar nicht um irgendein Mapping scheren. Ich iteriere von x bis x+n mit n < N und gut ist.

Noch ein gutes Beispiel: Wie soll der Index für in einem Stream aussehen? Insbesondere z.B. in der Standardeingabe?

volkard

Das mit dem Index kann man nur über zwei Wege lösen, fürchte ich:
a) Sie immer mitführen. Das hieße bei einem Baum aber Fürchterliches! Damit Einfügen effizient bleibt, kann kein Array benutzt werden, und es müßte als Index ein paralleler Baum geführt werden. Ich glaube, das fällt schon mal aus.
b) Der Index ist kurzlebig und Teil des Iteratores. Also beim Konstruieren des Iterators wird der Baum in-order-traversiert, was mit einer rekursiven Funktion eleganz geht, und ein Index-Array gebastelt. Aber oh, weh! Alle sublinearen Algorithmen, die auf diesem Index-Array laufen würden, würden bereits eine lineare Indizierungsphase bezahlen müssen.

Wie hast Du vor, einen Index für einen Baum zu machen?

Bashar

Tachyon schrieb:

Bashar schrieb:

Tachyon schrieb:

Wie willst Du denn mappen? Auf welcher Grundlage? Die Reihenfolge der Einfügung von Elementen? Aufgrund der Sortierung? Aufgrund irgendeines Prädikates? Was ist sinnvoll, und was nicht? Und wer entscheidet das?

Du argumentierst gerade gegen Iteratoren

Wieso das?

Ersetze im obigen Zitat "Wie willst du denn mappen?" durch "Wie willst du denn die Iterationsreihenfolge festlegen?". Bei einem Iterator musst du dich genauso entscheiden, wie der Container iteriert werden soll. Du versuchst, diese Entscheidung als willkürlich hinzustellen. Das ist sie in gewisser Weise auch, aber man trifft sie trotzdem irgendwie, zumeist findet sich auch ein natürlicher Kandidat.

Bei Iteratoren muss ich mich gar nicht um irgendein Mapping scheren. Ich iteriere von x bis x+n mit n < N und gut ist.

Damit hast du doch Indizes festgelegt. x+k entspricht dem Index k.

Noch ein gutes Beispiel: Wie soll der Index für in einem Stream aussehen? Insbesondere z.B. in der Standardeingabe?

Das scheitert aber nicht daran, dass man nicht weiß, wie man das Mapping festlegen soll. Das würde man einfach genauso machen wie mit dem Iterator. Man dürfte halt die Indizes nur sequentiell bearbeiten. Es ist halt unpraktisch, weil ein Stream selbst eine Abstraktion ist, die Random Access nicht zulässt.

Tachyon

Bashar schrieb:

Das scheitert aber nicht daran, dass man nicht weiß, wie man das Mapping festlegen soll. Das würde man einfach genauso machen wie mit dem Iterator. Man dürfte halt die Indizes nur sequentiell bearbeiten. Es ist halt unpraktisch, weil ein Stream selbst eine Abstraktion ist, die Random Access nicht zulässt.

Und was passiert bei einem Wraparound des Index? Wenn Du den sinnvoll zulassen willst, hast Du keinen Index mehr, sondern einen Iterator.

Mit dem Rest hast Du Recht. Das kann man auch so sehen.

volkard

Tachyon schrieb:

Und was passiert bei einem Wraparound des Index? Wenn Du den sinnvoll zulassen willst, hast Du keinen Index mehr, sondern einen Iterator.

Groß genug machen. 64 Bit. Das reicht bei 1000 Milliarden Zugriffen pro Sekunde, uups, nur ein halbes Jahr. 128 Bit reicht aber ne ganze Weile lang.

Bashar

BigNum Ich bestreite ja nicht, dass es unpraktisch ist.

Tachyon

volkard schrieb:

Tachyon schrieb:

Und was passiert bei einem Wraparound des Index? Wenn Du den sinnvoll zulassen willst, hast Du keinen Index mehr, sondern einen Iterator.

Groß genug machen. 64 Bit. Das reicht bei 1000 Milliarden Zugriffen pro Sekunde, uups, nur ein halbes Jahr. 128 Bit reicht aber ne ganze Weile lang.

Ich kann hier keine 64 Bit, geschweige denn 128 Bit. Lösung? Klasse basteln? -> Iteratoren.

Eisflamme

Okay. Bäume sind neben Random-Access und verketteten Listen ja eine weitere "Zugriffsart" (wenn man das so benennen möchte, zumindest muss man hier für neu überlegen und das möchte ich mit dem Begriff hier ausdrücken).

volkard:
Gut, das sehe ich ein, das wäre umständlich, inperformant oder speicherfressend. Der iterator wird sich einfach ein paar Infos merken und dann ist halt gut.

Hm... ja, da versagen Indizes dann schließlich in voller Breite. Dann mag ich Iteratoren jetzt vollkommen. Danke, das hat meinem Gesamtprogrammierverständnis ein klein wenig geholfen, glaub ich.

PS: Wieso lösen Iteratoren das Problem mit den 64 Bit? Wenn man nicht mehr adressieren kann, weil zu viel im Speicher liegt, hat man doch sowieso verloren?

volkard

Tachyon schrieb:

Ich kann hier keine 64 Bit, geschweige denn 128 Bit. Lösung? Klasse basteln? -> Iteratoren.

Och, aus 16-Bittern sich einen 128-Bitter zu basteln, der ++ kann und was ich hier nicht mache, + und -, das klingt nicht so schwer. * ist schon gemeiner und / ist gemein.

struct StreamIndex{
   unsigned short a,b,c,d;
   Index& operator++(){
      if(!++a)if(!++b)if(!++c)++d;
      return *this;
   }
   ...
};

Hmm, könnte recht lahm werden. Und natürlich, man kann nicht auf Streampositionen lesen, die schon gelesen wurden, also eigentlich ist es ein ForwardOnlyStreamIndex. Das ist schlimm, denn dann ist es doch nur ein Iterator, nur daß man nicht *i schreiben darf, sondern cont[i] schreiben muß und die Algorithmen mehr Übergabeparameter brauchen.

Tachyon

volkard schrieb:

[...]

Örks. Da finde ich es irgendwie einfacher, mir einen Iter... ach, lassen wir das.