Anfängerfrage zu Iteratoren

[Gast]

314159265358979 schrieb:

Ach vergiss es, ich gebs auf. Du bist zu blöd dazu. Ich kann dir meine Meinung so offensichtlich wie ich will in X Posts darlegen und du willst es trotzdem nicht kapieren. Vergiss es einfach, okay?

Sry, aber wenn ein Iterator sowas machen würde, das ... wäre einfach Dumm.

[314159265358979]

Nö. Für den Debugmodus durchaus brauchbar. Du hast einfach keine Ahnung, also stfu. <.<

[otze]

seid ihr euch immer noch am beleidigen wie Kleinkinder?

Und in der Tat kann man sagen, dass ein Iterator für Container nicht mehr als ein Wrapper um einen zeiger ist. Ob man ihn als "ref aufs erste Element/container + uint" oder "ref auf speicherzelle darstellt" ist ziemlich egal, da das äquivalente Darstellungen sind. Fakt ist, dass bei einem Container hinter dem was von einem Iterator referenziert wird eine echte Speicherstelle stecken muss. Von daher sind nicht so viele Darstellungen möglich.

Pi darf in dem Zusammenhang noch zeigen wie sein "container ref + unsigned int" noch die Anforderungen eines Iterators (operator=) erfüllt, also ohne das aus der container ref ein Zeiger wird.

[314159265358979]

Die Kernaussage ist einfach, dass man sich grundsätzlich nicht darauf verlassen kann. Natürlich haben die meisten Iteratoren intern Zeiger...

[Tachyon]

Es gibt Iteratoren, zu denen gibt es nicht einmal einen Container. Zum Beispiel wären Iteratoren denkbar, die Werte generieren. Da hast Du dann intern keine Zeiger, sondern einen Algorithmus zur Berechnung des nächsten Wertes.
Ich habe z.B. hier eine Funktion, die ein Iteratorpaar liefert, dass FIR-Tiefpasskoeffizienten berechnet, wenn man drüber iteriert. Da gibt es intern weder einen Zeiger, noch einen Container.

[SeppJ]

vector<bool>::iterator?

[Tachyon]

SeppJ schrieb:

vector<bool>::iterator?

Jo, das ist auch gut.

[Shade Of Mine]

Ein Zeiger ist ein Iterator aber ein Iterator ist kein Zeiger.

Es wird manchmal falsch rum interpretiert. Insofern sind sie sich schon ähnlich, ein Zeiger ist nichts anderes als ein Spezialfall eines Iterators.

[otze_logout]

SeppJ schrieb:

vector<bool>::iterator?

ist kein Container. Meine Aussage galt fuer Container.

[Shade Of Mine]

otze_logout schrieb:

SeppJ schrieb:

vector<bool>::iterator?

ist kein Container. Meine Aussage galt fuer Container.

Was ist für dich dann ein Container?

Aber OK, ich kann einen bitset Container implementieren der alle Anforderungen eines Containers entspricht...

[Gast]

Shade Of Mine schrieb:

otze_logout schrieb:

SeppJ schrieb:

vector<bool>::iterator?

ist kein Container. Meine Aussage galt fuer Container.

Was ist für dich dann ein Container?

Seine Aussage ist btw Standardisiert. Gab dazu vor kurzem hier einen Thread.

[Shade Of Mine]

Hacker schrieb:

Seine Aussage ist btw Standardisiert. Gab dazu vor kurzem hier einen Thread.

Ich wüsste kein requirement für einen Container der mich daran hindert ein bitset zu implementieren. Bis auf dass reference immer value_type& sein muss. Aber das ist ja nun auch echt mal ne sehr zufällige Anforderung.

Alternativ kann ich mir einen virtuellen Container vorstellen der keine Werte direkt speichert sondern nur eine Formel um die Werte zu generien. zB eben eine Funktion f(x)=2x oder derartiges.

[Gast]

Shade Of Mine schrieb:

Hacker schrieb:

Seine Aussage ist btw Standardisiert. Gab dazu vor kurzem hier einen Thread.

...

Ich meinte, die Aussage dass std::vector<bool> kein Container ist.

[SeppJ]

Hacker schrieb:

Shade Of Mine schrieb:

Hacker schrieb:

Seine Aussage ist btw Standardisiert. Gab dazu vor kurzem hier einen Thread.

...

Ich meinte, die Aussage dass std::vector<bool> kein Container ist.

Es kommt aber bis auf eine Kleinigkeit der Idee sehr nahe. Es ist nicht so schwer, sich reguläre Container vorzustellen, die ein bisschen komplexer aufgebaut sind. Meinetwegen ein Container zum Verwalten von chars, der aus irgendeinem Grund intern die Daten als long long hält (vielleicht so eine Art deque für Arme). Da könnte man leicht die Containeranforderungen erfüllen, der Iterator wäre dann aber doch ein komplizierteres Konstrukt.

Apropos deque: Ein deque-Iterator hat beim GCC im Release eine Größe von 4 Pointern. Überhaupt kann ich mir bei einer deque nicht vorstellen, dass es überhaupt möglich ist, einen Iterator zu konstruieren, der nur mit einem Pointer auskommt.

Nochmal eine Übersicht über den aktuellen GCC:

Vector: 8
Vector<bool>: 16
List: 8
Deque: 32
Map: 8
Set: 8

[Gast]

SeppJ schrieb:

teres Konstrukt.

Apropos deque: Ein deque-Iterator hat beim GCC im Release eine Größe von 4 Pointern. Überhaupt kann ich mir bei einer deque nicht vorstellen, dass es überhaupt möglich ist, einen Iterator zu konstruieren, der nur mit einem Pointer auskommt.

Vielleicht ist der Iterator selbst ein Knoten... warte, ich bin schon wieder verwirrt mit diesem Pointergefummel und verketten Listen...

[SeppJ]

Hacker schrieb:

SeppJ schrieb:

teres Konstrukt.

Apropos deque: Ein deque-Iterator hat beim GCC im Release eine Größe von 4 Pointern. Überhaupt kann ich mir bei einer deque nicht vorstellen, dass es überhaupt möglich ist, einen Iterator zu konstruieren, der nur mit einem Pointer auskommt.

Vielleicht ist der Iterator selbst ein Knoten... warte, ich bin schon wieder verwirrt mit diesem Pointergefummel und verketten Listen...

Auf jeden Fall bist du jetzt Mal am Zuge, eine gültige (denk an die Komplexitätsanforderungen!) deque zu konstruieren, deren (gültiger) Iterator mit einem einzigen Pointer auskommt. Ansonsten wirst du, wie du es schon vor 3 Seiten hättest tun sollen, wohl eingestehen müssen, dass Pi absolut Recht hat. (und otze wird das wohl auch müssen)

[pyhax]

Shade Of Mine schrieb:

Bis auf dass reference immer value_type& sein muss. Aber das ist ja nun auch echt mal ne sehr zufällige Anforderung.

Könnte man nicht für value_type z.B. BitValue nehmen und dann als referene BitValue& ?

[Gast]

SeppJ schrieb:

Hacker schrieb:

SeppJ schrieb:

teres Konstrukt.

Apropos deque: Ein deque-Iterator hat beim GCC im Release eine Größe von 4 Pointern. Überhaupt kann ich mir bei einer deque nicht vorstellen, dass es überhaupt möglich ist, einen Iterator zu konstruieren, der nur mit einem Pointer auskommt.

Vielleicht ist der Iterator selbst ein Knoten... warte, ich bin schon wieder verwirrt mit diesem Pointergefummel und verketten Listen...

Auf jeden Fall bist du jetzt Mal am Zuge, eine gültige (denk an die Komplexitätsanforderungen!) deque zu konstruieren, deren (gültiger) Iterator mit einem einzigen Pointer auskommt. Ansonsten wirst du, wie du es schon vor 3 Seiten hättest tun sollen, wohl eingestehen müssen, dass Pi absolut Recht hat. (und otze wird das wohl auch müssen)

Ja, leider hat PI Recht. Wie ich auch eben in meinem GCC gefunden hab, hat ein Deque-Iterator folgende Member-Variablen:

_Tp* _M_cur;
      _Tp* _M_first;
      _Tp* _M_last;
      _Tp** _M_node;

Jaja, ich geb schon auf, ich bin dumm.

[314159265358979]

Hacker schrieb:

Jaja, ich geb schon auf, ich bin dumm.

Nö. Du bist nur naiv und unerfahren.