Reverse-Iterator-Klasse als Adapter, oder ableiten??

smooth_op

Huhu,

ist es besser den reverse_iterator meines eigenen Containers von der normalen iterator-Klasse abzuleiten, oder mit Hilfe eines Iteratorobjekts in der reverse_iterator Klasse zu arbeiten?

Beim ableiten muss ich mich ja nur um ++, --, kümmern, diese entsprechend "überladen"? und die anderen Methoden einfach ignorieren bzw implizit die Originale(::iterator) nutzen.

Beim Adapter müsste ich jede Methode nochmal hinschreiben und den Aufruf für das darunter liegende iterator-Objekt tätigen, right? Dort kann ich dann einfach Inkrement und Dekrement vom Objekt vertauschen, um richtige Semantik zu erreichen und fertig.

Was meint ihr?

camper

Dafür gibt es std::reverse_iterator.

smooth_op

Wow ja, das hilft weiter.
Ich geb dir die Mail von meinem Prof, erklärs dem.

Geht nur um die Design-Entscheidung und damit verbundenen Vor- und Nachteile.

*Edit
Was mir noch einfällt. Beim Ableiten muss ich auch alle Methoden neu Deklarieren und Definieren, zumindest mal den ::iterator Std.Ktor aufrufen usw.
Daher ist der Adapter wohl doch einfacher?!

a_xel

Hi smooth_op,

camper will mit seiner Antwort sagen, das du eigentlich keinen eigenen reverse_iterator implementieren musst, vorausgesetzt dein Container ist entsprechend STL kompatibel

Poste doch mal deinen Container code.

ghorst

@a_xel nicht der container muss dafür stl-compatibel sein, sondern der iterator.

@smooth_op camper hat doch auch schon gesagt, welche variante er bevorzugt: den adapter. der std::reverse_iterator ist so zu implementieren. zum nachlesen c++-standard "24.4.1.1 - Template class reverse_iterator"

das bietet sich auch, da es semantisch wenig sinnvoll ist, den reverse_iterator als kindklasse des iterators zu betrachten, sondern sie stellen nur zwei verschiedene interfaces für das gleiche da.

a_xel

@ghorst,

danke für die Korrektur, war wohl zu spät gestern abend
ich meinte natürlich den iterator

hier ein link, ich hoffe er hilft:

http://www.sgi.com/tech/stl/ReverseIterator.html

smooth_op

Hi zusammen!

Problem ist, dass die Liste vollständig unabhängig, jedoch kompatibel zur STL sein muss, was sie bisher auch ist.
Daher fallen mir nur meine beiden Varianten ein, um den Code kürzer zu bekommen.
Momentan stehen alle drei Iterator-Klassen untereinander in der Container-Klasse und jede einzelne Methode der Iterator-Klassen in der cpp. Da die Liste entsprechend vollständig ist, scroll ich mir mittlerweile nen Wolf.

Also noch ein Vorschlag, auch wenns semantsich nicht 100% sinnig erscheint, wie ghorst bemerkte.

ghorst

da habe ich mich wohl missverständlich ausgedrückt. wenn du den std::reverse_iterator nicht nehmen darfst, so solltest du doch die idee des adapters benutzen und dann aus reiner faulheit einen template-adapter analog zu dem std::reverse_iterator schreiben.

welches ist dein dritter iterator?

ansonsten: wenn du den weg über einen allgemeingültigen reverse_iterator-template gehst, kannst du dessen inhalt auch aus deiner klasse auslagern.

camper

Ich sehe immer noch nicht, wo eigentlich das Problem liegt. Ich füge aber mal hinzu, dass das ganze kein Designproblem ist. Das Design bestimmt, wie eine bestimmte Komponente zu benutzen ist (also die Betrachtung von außen). Diese Frage wird aber bereits durch die abstrakte Beschreibung im Standard bestimmt. Hätte aber deine Implementation Einfluss auf die Benutzbarkeit, dann wäre sie fehlerhaft. Es ist mittlerweile Mode geworden, jedes kleine Problemchen als Designfrage hinzustellen. Das entleert den Begriff allerdings jeden Gehalts.

smooth_op

@camper
ok, dann habe ich das Wort im falschen Kontext verwendet.
Dachte man versteht auf was ich hinaus wollte. Ich danke für deinen ausführlichen Korrekturhinweis

@ghorst
Die Iteratoren sollten schon weiterhin Klassen innerhalb der Container-Klasse sein.
Also sowas:

template <typename T>
class mylist
{
...
...
...
  class iterator {
      public:
        // Die STL Typen
        typedef typename mylist<T>::value_type value_type;
        typedef typename mylist<T>::pointer pointer;
        typedef typename mylist<T>::reference reference;
        typedef typename mylist<T>::difference_type difference_type;
        typedef std::bidirectional_iterator_tag iterator_category;
      ...
      ...
      ...
  };

  class reverse_iterator {
      ...
      ...
      ...
  };

};

Dein Weg wäre nicht schlecht, aber wohl zuweit von der Vorgabe.
Die dritte Iterator-Klasse ist übrigens der const_iterator.
Ich werde es dann wohl einfach als Adapter immplementieren und schauen, obs Nachteile bringt. Soweit ich weiss, kann ich dort dann alle Methoden im Header inline definieren und die cpp wird schlanker.
Danke dir!