Ich verstehe das Prinzip eines Random Access Iterators nicht.
Gehe ich richtig in der Annahme, dass durch einen solchen Iterator zwar alle Elemente z.b. eines Vectors durchgegangen werden, allerdings in einer beliebigen Reihenfolge?

Macht es dann überhaupt Sinn mittels einer for Schleife wie folgt zu iterieren?:

std::vector<SomeObject>::iterator it;
for(it = myObject.begin(); it != myObject.end(); ++it) {
(*it) ... //do some stuff
}

Laut der Referenz auf http://www.cplusplus.com/reference/stl/vector/begin/ und dem Beispiel da, sollte der iterator aber linear vom ersten Element des Vektors vorwärts gehen.

Könnte die Reihenfolge der ausgegebenen Zahlen auch anders sein? Z.b. 4 5 1 2 3 ?

vittel schrieb:

Könnte die Reihenfolge der ausgegebenen Zahlen auch anders sein? Z.b. 4 5 1 2 3 ?

Nein. Random Access heisst genau das, was es bedeuten soll. Man kann auf jedes Element direkt in O(1) zugreifen. Beispiel:

std::list<int>::iterator listIter = ...;
std::vector<int>::iterator vecIter = ...;

std::advance(listIter, 5);  // braucht 5 Schritte.
std::advance(vecIter, 5);   // braucht einen Schritt.

Grüssli

Ich verstehe nun wie der RAndom Access Iterator funktioniert, resp. warum er so heisst. Wie ich durch dein Beispiel sehe, haben Listen entsprechend keine R.A. iteratoren. Trotzdem sollte mein Code doch funktionieren:

RotoPathList::const_iterator it;
RotoPathList::const_iterator it2;
//_rc and _rcB have always the same number of elements!
for(it = _rc->begin(), it2 = _rcB->begin(); it != _rc->end(), it2 != _rcB->end() ; ++it, ++it2){
// do some stuff
}

it2 verhält sich meiner Meinung nach korrekt und zeigt aufs erste Element.
it zeigt allerdings jedesmal auf ein Element in der mitte der liste und arbeitet dann das nächst niedrigere Elemente ab... ?? ( also z.b. start bei 8. dann 7. ..etc bis 1. dann 12. 11... etc bis 9. )

Woran liegt das?

Woran liegt das?

Kann ich mit dem wenigen Code, welchen du gezeigt hast, nicht sagen. Ich weiss noch nicht einmal, von welchem Typ _rc und _rcB genau ist. Bzw. was eine RotoPathList sein soll.
Ich weiss nicht wie du ausgibst, ich weiss nicht, was in den Container sein soll. Ich weiss nicht wie du einliest. Ich habe 0 relevante Informationen, daher kann ich dir unmöglich helfen

Das einzige was ich erkennen kann, ist ein Fehler, welcher aber nichts mit dem Problem zu tun haben kann, welches du beschreibst:

for(it = _rc->begin(), it2 = _rcB->begin(); it != _rc->end() && it2 != _rcB->end() ; ++it, ++it2)
// ...

Das mittlere Komma durch ein && ersetzt. Es sollen ja wohl beide geprüft werden und nicht zwei Anweisungen hintereinander ausgeführt werden

Grüssli

Zu den Typen:

RotoPathList ist eine std::list<..>

Der Rest sollte nicht wichtig sein, oder? ( _rc, _rcB sind Instanzen einer Klasse namens RotoCurves, dessen 'Hauptvariable' eine Liste ist, -> const_iterator der Liste erhält man über _rc->begin() )

Aber eigentlich egal was das ist, grundsätzlich sollte das Ganze so klappen, richtig?

Worin liegt der Unterschied eines const_iterators und eines iterators?
Möglich dass es durch die Verwendung des const_iterators Probleme gibt ?

_rc, _rcB

Variablen mit einem '_' beginnend sollten nicht verwendet werden (17.4.3.1.2 Global names).

_rc, _rcB

Variablen mit einem '_' beginnend sollten nicht verwendet werden (17.4.3.1.2 Global names).

Spielt doch innerhalb eines lokalen (lies: nicht-globalen) Scopes keine Rolle. C++ ist schließlich statisch und nicht dynamisch scoped.

knivil schrieb:

_rc, _rcB

Variablen mit einem '_' beginnend sollten nicht verwendet werden (17.4.3.1.2 Global names).

Spielt doch innerhalb eines lokalen (lies: nicht-globalen) Scopes keine Rolle. C++ ist schließlich statisch und nicht dynamisch scoped.

Der Präprozessor aber nicht.

Ich weiss nicht wie du ausgibst, ich weiss nicht, was in den Container sein soll. Ich weiss nicht wie du einliest.

Einlesen via list.push_back(object). Zur gebe ich bei jedem hinzufügen eines neuen Elements dieses auch auf die Console aus.

Wenn ich nun in der for schleife die Elemente wieder ausgebe sehe ich, dass es nicht mehr in der gleichen Reihenfolge ist..

Lokaler Scope schrieb:

knivil schrieb:

_rc, _rcB

Variablen mit einem '_' beginnend sollten nicht verwendet werden (17.4.3.1.2 Global names).

Spielt doch innerhalb eines lokalen (lies: nicht-globalen) Scopes keine Rolle. C++ ist schließlich statisch und nicht dynamisch scoped.

Der Präprozessor aber nicht.

.. danke für die Hinweise. Ändern der Namen auf rc & rcB hat jedenfalls nichts am Verhalten verändert.

Lokaler Scope schrieb:

knivil schrieb:

_rc, _rcB

Variablen mit einem '_' beginnend sollten nicht verwendet werden (17.4.3.1.2 Global names).

Spielt doch innerhalb eines lokalen (lies: nicht-globalen) Scopes keine Rolle. C++ ist schließlich statisch und nicht dynamisch scoped.

Der Präprozessor aber nicht.

dann lest halt noch ma im standard...

_x ist ok
_X ist reserviert
__x ist reserviert
__X ist reserviert

also ist _rcb iO...

Dravere schrieb:

Das mittlere Komma durch ein && ersetzt.

kommt imho aufs selbe hinaus?!

bb

Dravere schrieb:

Das mittlere Komma durch ein && ersetzt.

kommt imho aufs selbe hinaus?!

Wenn du schon im Standard liest, dann lies das doch bitte auch noch nach! Aber ganz sicher ist das nicht das gleiche! Oder machst du auch sowas?

if(i > 0, i < 10)
// statt
if(i > 0 && i < 10)

@Vittel,
Aber es wäre ja auch möglich, dass du die Zahlen in einer anderen Reihenfolge einliest, nicht? Also dass sie in der falschen Reihenfolge im Container sind? Die Iteratoren werden jedenfalls nicht von sich aus irgendwie kreuz und quer über die Liste gehen.

Grüssli

@Vittel,
Aber es wäre ja auch möglich, dass du die Zahlen in einer anderen Reihenfolge einliest, nicht? Also dass sie in der falschen Reihenfolge im Container sind? Die Iteratoren werden jedenfalls nicht von sich aus irgendwie kreuz und quer über die Liste gehen.

Grüssli

Ja, in der Tat scheint sich irgendwo vorher schon ein Fehler eingeschlichen zu haben. Das Problem liegt nicht bei den Iteratoren. .. ich suche mal weiter.

Vielen Dank für eure Hilfe!!

unskilled schrieb:

Dravere schrieb:

Das mittlere Komma durch ein && ersetzt.

kommt imho aufs selbe hinaus?!

Wenn du schon im Standard liest, dann lies das doch bitte auch noch nach! Aber ganz sicher ist das nicht das gleiche!

hmm... dachte, das scho mal so bei ner for-schleife gesehen zu haben - aber offenbar nimmt er wirklich nur das ergebnis des vergleichs ganz rechts...

sry

also ist _rcb iO...

Es ist das risiko nicht wert.
Was bringt dir der leading underscore? nichts.
Aber du kannst in ganz dumme probleme reinlaufen.
Das ist nämlich kein juristisches Problem sondern ein praktisches.

unskilled schrieb:

also ist _rcb iO...

Es ist das risiko nicht wert.
[...]
Aber du kannst in ganz dumme probleme reinlaufen.

oO
welches risiko habe ich damit denn?
imho ist der compiler eh nichts wert, wenn sie sich nich an diese konventionen hält - und dort steht nu ma eindeutig, dass _kleinerBuchstabe max. funktionsnamen oder konstanten sind - aber keine macros...

bb

edit: ich mag den (leading) underscope bei parametern - besonders im ctor, weil ichs nich mag, wenn variablennamen gleich heißen.

tclass (int x) : x(x) {}
//vs.
tclass (int _x) : x(_x) {}

Es gibt in einigen Compilern bezeichner mit _ und kleinbuchstabe am Anfang und von irgendwelchen libraries will ich garnicht erst sprechen.

Es ist ja zB so, dass folgender Code nicht portabel:

namespace geheim {
int max(int a, int b) {
  return a>b?a:b;
}
}

Die Welt ist kein Wunschkonzert

Statt leading underscore könntest du zB trailing underscore nehmen...
Wobei ich sowas generell unnötig finde, aber ok.

und du kannst hier nicht mit irgendeinem header ankommen und sagen, dass er sich net an den standard hält - erstens tut er das, weil er keinen für den compiler reservierten bez. gewählt hat und zweitens kann man es ja nu echt deaktiveren - und ich kenne wenige, die die windows.h so include, wie sie ist - eigtl hat jeder nen (leider recht kleinen ^^) wrapper dafür - selbst, wenn der nur NO_MIN_MAX umfasst...

allerdings hat das alles nix mit dem unterstrich am anfang zu tun...

bb

hmm... dachte, das scho mal so bei ner for-schleife gesehen zu haben - aber offenbar nimmt er wirklich nur das ergebnis des vergleichs ganz rechts...

Meinst du nicht sowas wie ++i, ++j im Aktualisierungs-Teil der For-Schleife? Da ist es nämlich irrelevant, was zurückgegeben wird, da nur die Seiteneffekte zählen.

Aber operator&& wertet den rechten Operanden nur aus, falls der linke true ergibt, und gibt in diesem Fall das logische Und zurück. Während operator, beide Ausdrücke (zuerst links, dann rechts) auswertet und das Ergebnis des rechten zurückgibt. Nur, falls das noch nicht klar war...