spieleprogrammierer.de - Forum und Wiki zur Spieleprogrammierung und Spieleentwicklung

Zitat von »BlueCobold«

Zitat von »denniro«

Zitat von »BlueCobold«

Wenn ich Deinen "Beruf" so sehe, dann war ich damals nur ca. 2-3 Jahre älter als Du

Boah manchmal frage ich mich echt, wann ihr damit angefangen habt xDD

In Deinem Alter Ich habe aber auch mit 3 Sprachen und System-naher Entwicklung mit Assembler, Intel-Spezifikationen in der Hand und VGA-Dokumenten unter'm Arm angefangen
Hach ja... jetzt mach' ich nur noch ganz anderes Zeug.

Zitat von »Schrompf«

Die Illustration für einen Iterator wäre eher:

Ein Mann, der vor einem Schließfach am Bahnhof steht. Der Mann weiß, wie er zum nächsten Schließfach kommt, und er kann das Gepäckstück aus dem Schließfach für Dich rausholen oder was daran machen. Du musst nicht mehr wissen, wo die Schließfächer stehen oder ob es evtl. den Gang runter noch weitere Schließfächer gibt - das merkt sich der Mann für Dich. Du kannst ihm aber sagen: geh zum nächsten, geh weiter, geh weiter.

Manche Iteratoren können außerdem zurückgehen oder gar beliebige Schritte (z.B. drei Fächer vor) machen. Das hängt dann aber vom Container ab, für den der Iterator gilt.

Die Grenzen darfst Du Dir nicht vorstellen, als ob der Mann sofort erfährt, wenn ein neues Schließfach aufgestellt wird. Das ist nämlich explizit nicht der Fall! Nur Visual Studio hat da zusätzliche Logik eingebaut, so dass der Mann davon erfährt. Das Prinzip ist eher so, dass man mittels weiterer Männer einen Bereich absteckt, zwischen denen der Mann umherlaufen kann. ein bla.begin() ist quasi ein Mann, der vorne am ersten Schließfach lümmelt. Ein bla.end() ist ein Mann, der !hinter! dem letzten Schließfach steht. Und wenn Dein Iteratormann soweit gelaufen ist, dass er dem Ende-Mann ins Gesicht blickt, bist Du am Ende des abgesteckten Bereichs angekommen. Du darfst dort aber schon nicht mehr ins Schließfach greifen, weil Dein Mann ja nicht vor einem Schließfach steht, sondern vorm Endmann.