Random Access Iterator [gelöst]

vittel

Ok, hab nun das , durch ein && ersetzt. merci.

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 ?

knivil

_rc, _rcB

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

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.

Shade Of Mine

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.

vittel

Dravere schrieb:

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..

vittel

Shade Of Mine schrieb:

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.

unskilled

Shade Of Mine schrieb:

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

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! 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

Dravere schrieb:

@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

Dravere schrieb:

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

Shade Of Mine

unskilled schrieb:

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

Shade Of Mine schrieb:

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) {}

Shade Of Mine

Die reale Welt ist kein Wunschkonzert...

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.

unskilled

WinAPI is nun mal was anderes - und da gibts noch sehr viel mehr, was eigtl gültige bezeichner ersetzen möchte...
aber das wird ja _jede_ lib so machen, dass sie bestimmte defines hat, aber nich die vom compiler reservierten bezeichner wählen möchte - aber auch da kenn ich nur CAPS_BEZEICHNER und keine mit unterstrich am anfang...

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

Nexus

unskilled schrieb:

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...