Softwareentwicklung in C++ - ASC

e v e r s e−i t e r a t i n g vector :
9 8 7 6 5 4 3 2 1 0
. . . and back to the s t a r t :
0 1 2 3 4 5 6 7 8 9
16.4 Allocators 517
In Abbildung 16.1 findet sich eine schematische Darstellung des soeben Beschriebenen.
Die Kästchen stellen die einzelnen Elemente dar, die Pfeile
zwischen den Kästchen stehen für eine Navigationsrichtung und sind jeweils
mit ++ bzw. -- gekennzeichnet, um zu zeigen, welcher Operator für einen Iterator
nun in welche Richtung navigiert. Zusätzlich ist noch zu sehen, worauf
die Iteratoren zeigen, die man mittels begin, end, rbegin und rend anfordert.
In der Graphik ist auch zu erkennen, warum ein Iterator und ein reverse
Iterator verschiedene Datentypen sein müssen, denn sie zeigen in Bezug auf
die Navigation ja völlig unterschiedliches Verhalten.
Iterator:
begin() end()
reverse Iterator:
rbegin()
++ ++
++ ++
0 1
...
8 9
−− −−
−− −−
++ ++
++ ++
9 8
...
1 0
−− −−
−− −−
++
−−
++
−−
rend()
Abbildung 16.1: Iterator und reverse Iterator schematisch dargestellt
16.4 Allocators
Allocators werden an dieser Stelle nur der Vollständigkeit halber erwähnt,
um allen Lesern bewusst zu machen, wie die STL beim Anfordern von Memory
vorgeht. Die STL geht davon aus, dass intern keine fixen Annahmen
getroffen werden dürfen, auf welche Art für welche Objekte Memory angefordert
werden soll (wie schon erwähnt, die STL ist Policy-frei!). Würden die
in der STL implementierten Datenstrukturen grundsätzlich Objekte hardcodiert
mittels new und delete anfordern, so könnte es sein, dass sie damit in
speziellen Fällen gegen die Intention der Applikation verstoßen, denn sowohl
für Elemente in Containern als auch für interne Objekte der Datenstrukturen
könnte ein spezielles Memory Management erwünscht sein.