Iterator Frage die Zweite

Simon2

lettort schrieb:

Besser oder nicht Besser ist doch gar nicht die Frage....

Naja:

lettort schrieb:

...Wo ist dann bitte der Sinn dahinter?...Schade und auch nicht sinnig ...obwohl es nicht sein müsste...

Das klingt schon kaum noch "wertfrei".

lettort schrieb:

...hätte etwas machen sollen wo ich z.B. auf "iterator.hasNext()" (http://java.sun.com/j2se/1.4.2/docs/api/java/util/Iterator.html) reagiere, in einer while-schleife....Schade und auch nicht sinnig - aus objektorientierter Sicht gesehen.

also spätestens DA hast Du doch Deinen "2. iterator" ... wo ist denn der Unterschied zwischen "!=end()" und "hasNext()" ?
Kann es sein, dass Du "iterator" als vollwertiges Objekt nicht wahrgenommen hast, sondern nur als "emantisches Konstrukt zur Durchführung einer Schleife" ?
Was soll an zweiter const-iteratoren, die Anfang und Ende einer Liste kennzeichnen verwerflich sein ?

Ach ja: Eventuell wirds auch beim Thema "const" ein wenig schwammig, wenn man von Java herkommt.

Gruß,

Simon2.

P.S.: Noch eine Frage: Gibt's bei Java eigentlich auch previous()/hasPrevious() ?

Artchi

Dein Problem ist, das du sagst "DAs was Java macht, ist sauberer.". Gut, das ist deine Meinung. Aber letztendlich ist !=null fachlich gesehen, nicht logisch. Weil ich damit nur überprüfe, ob ein Itertor auf null zeigt. Aber hat das was mit DEM Ende zu tun?

Letztendlich beisst du dich auf end() fest, obwohl es überhaupt keinen Grund gibt. Was stört dich an end()? Es ist sogar eine aussagefähige Methode, es sagt "Da ist DAS Ende." Schöner kann eine Hochsprache etwas nicht aussagen. null heißt eigentlich nur in Pointer-Jargon "ungültig". Macht im Container eigentlich wenig Sinn.

Stört dich die Performance? Es gibt dadurch keinen Nachteil.

Stört dich die Schreibarbeit? Gut, kann sein, ich tippe ein paar Buchstaben mehr ein. Super! In dem Fall ist das Iterator-Konzept gescheitert.

Also, man kann sich auch "anstellen" und haarspalterei betreiben.

lettort

Nur um es mal klarzustellen - ich bin an diese Diskusion völlig wertefrei herangegangen, da ich in beiden Programmiersprachen Vor- und Nachteile sehe und beides gern einsetze.

Was momentan wohl etwas untergegangen ist, ist die Tatsache das ich bei C++ einen Iterator .begin und einen Iterator .end vom Vector hole. Bei Java hat der Iterator selbst eine Ahnung über sein .end und .begin.

Shade Of Mine

lettort schrieb:

Find ich halt Schade und auch nicht sinnig - aus objektorientierter Sicht gesehen.

Begruendung?

"Weils bequemer ist" zaehlt nicht.
Es hat nichts mit objekt orientierung zu tun ob du immer ein iteratoren paar brauchst oder nicht.

was zaehlt ist die abstraktion - und da tut es nichts zur sache ob du 1 oder 100 iteratoren brauchst...

unbequem ist es manchmal, ja. aber bequemlichkeit ist kein konzept der OOP...

RHBaum

@lettort

kenn mich in java ned so aus. Aber gilt dein iterator auch fuer maps (assoziative container, key - wert Speicher) ?

wenn ja, dann schreib mal wie man in java ueber so ne map iterieren wuerd, wenn man zb alle keys von 10 - 100 haben wollt (integer - irgendwas map) !
Bin echt neugierig wie java da einen untrstuetzt ...

Ciao ...

Simon2

lettort schrieb:

...Was momentan wohl etwas untergegangen ist, ist die Tatsache das ich bei C++ einen Iterator .begin und einen Iterator .end vom Vector hole. Bei Java hat der Iterator selbst eine Ahnung über sein .end und .begin.

DAS stimmt natürlich !
Ist halt die Frage, ob Anfang und Ende eher Eigenschaften eines Iterators oder eines Containers ist ... ich persönlich empfinde es eher als Container-Eigenschaften ("Am Ende einer Liste ... der Anfang einer Tabelle ..."); aber das ist erstmal emotional begründet.

Gruß,

Simon2.

lettort

Man kann jetzt wieder viel philosophieren...

Ein Iterator ist doch ein Objekt, welches einen Containerinhalt schrittweise wiedergeben kann. Wenn dieses Objekt also einen Inhalt besitzt, dann wäre es doch sinnig, dass es über sein eigenes Ende bescheid weiss.

Es kann ja nicht im OO-Kontext sein, dass ein Aussenseiter sich noch Gedanken darüber machen muss, dass er ein Ende "überfährt".

So Jungens und Mädels, ich danke für die anregende Diskusion, muss sie aber leider auf Morgen vertagen!
Wünsch euch allen das Beste!

@RHBaum
Ich hoffe ich vergesse es bis morgen net. Will dran denken und dir ne Lösung geben.

RHBaum

Naja, das empfinden entwickelt sich auch ^^

Als ich mein erstes template gesehen hab, dacht ich nur noch : "Um Gottes willen, was ist das denn ?".
Mittlerweile find ich templates elegant und schoen ^^

Denk mal das Java programmierer da echt etwas anders gepraegt sind, und mit c++ erst mal bisserl warm werden muessen.

ob das begin und end am iterator ist, iss fuer mich ned nur ne geschmackssache ... sondern auch ne frage der performance und der flexibilitaet der iteratoren.

Ciao ...

Simon2

lettort schrieb:

...
Ein Iterator ist doch ein Objekt, welches einen Containerinhalt schrittweise wiedergeben kann. Wenn dieses Objekt also einen Inhalt besitzt, dann wäre es doch sinnig, dass es über sein eigenes Ende bescheid weiss....

Für mich ist ein iterator eher ein inhaltsloses Objekt ... eber ein "mobiler Griff", den man über die Elemente eines Containers schieben und über den man auf das jeweilige Objekt geeignet (const oder nicht) zugreifen kann. (bei const_iterator habe ich immer das Bild einer "Lupe" vor Augen).
Den Iterator zu fragen, ob in dem Container, auf den ich ihn geschoben habe, noch Elemente (davor ? danach ?) sind, emfpinde ich eben als nicht natürlich.
BTW: Gibt's in Java auch bidirectionale oder Random-Access-Iteratoren ? Immerhin kann ich mich in C++ auch mittels "--it" oder "it += 3" über eine Liste bewegen ... da ist ein "hasNext()" wenig hilfreich.

Schönen Abend noch,

Simon2.

Shade Of Mine

lettort schrieb:

Ein Iterator ist doch ein Objekt, welches einen Containerinhalt schrittweise wiedergeben kann. Wenn dieses Objekt also einen Inhalt besitzt, dann wäre es doch sinnig, dass es über sein eigenes Ende bescheid weiss.

ja, und?

Es waere auch "sinnig" dass ein Vogel eine "flieg()" methode hat, oder?
Aber die Erfahrung hat gezeigt, dass n Pinguin und ein Strauss Voegel sind die nicht fliegen koennen.

Ist es jetzt un-oo wenn ich Behaviors einbaue?

Es kann ja nicht im OO-Kontext sein, dass ein Aussenseiter sich noch Gedanken darüber machen muss, dass er ein Ende "überfährt".

Warum?

Das sind ploetzlich 2 verantwortungen in einem Objekt:

ist es ein iterator im C++ sinne - also ein "zeiger" auf den inhalt der Collection
und
ist es ploetzlich eine iteratoren-range.

Ist das nicht genauso eine Schwachstelle wie dass man in c++ immer ein iteratoren paar braucht?

Was ist jetzt besser? Was ist mehr OO?

Ist es nicht einfach so, dass es 2 Loesungen fuer 1 Problem sind?

Dass Iterator in Java eher ein IteratorRange ist? Ein high level konzept. und das iteratoren konzept in C++ eher low leveliger?

OT:
wenn dir soviel daran liegt dass iteratoren eine range sein sollen, dann mach doch eine iterator_range klasse die ein iteratore paerchen nimmt und deine .next und so methoden anbietet.

Artchi

Ein Iterator ist doch ein Objekt, welches einen Containerinhalt schrittweise wiedergeben kann. Wenn dieses Objekt also einen Inhalt besitzt, dann wäre es doch sinnig, dass es über sein eigenes Ende bescheid weiss.

Nein, ein Iterator ist nur ein Pointer (wenn auch ein schlauer). Er zeigt nur wo etwas im Container drin liegt, er selbst hat kein Inhalt aus dem Container.

DEvent

Artchi schrieb:

Ein Iterator ist doch ein Objekt, welches einen Containerinhalt schrittweise wiedergeben kann. Wenn dieses Objekt also einen Inhalt besitzt, dann wäre es doch sinnig, dass es über sein eigenes Ende bescheid weiss.

Nein, ein Iterator ist nur ein Pointer (wenn auch ein schlauer). Er zeigt nur wo etwas im Container drin liegt, er selbst hat kein Inhalt aus dem Container.

Stimmt, ist auch in Java so. Nur weis der Iterator in Java wo er sich grade befindet (im Container).

Aber Shade Of Mine hat soweit Recht, es sind einfach nur 2 Lösungen für das selbe Problem.

@RHBaum:
Eine Map<K, V> hat

public Set<Map.Entry<K,V>> entrySet();

Der Set hat dann einen Iterator<Map.Entry<K,V>>.

BTW: Gibt's in Java auch bidirectionale oder Random-Access-Iteratoren ? Immerhin kann ich mich in C++ auch mittels "--it" oder "it += 3" über eine Liste bewegen ... da ist ein "hasNext()" wenig hilfreich.

In Java ist halt ein anderes Container-Konzept als in der STL.

Für it+=3 kannst du gleich vector.get(i*3) verwenden, RandomAccess ist sowieso nur bei Vectors sinnvoll, weniger bei Listen.

Für --it hast du den ListIterator<E>, mit hasPrevious() und previous().

Werner Salomon

lettort schrieb:

Dann brauche ich ja trotzdem 2 Iteratoren - begin und end. Einem zum Starten der dann gegen den Zweiten läuft.

Wo ist dann bitte der Sinn dahinter? Kann dann auch gleich in einer Schleife direkt aus dem Vector mir die Werte geben lassen und ständig überprüfen ob Vector::size() erreicht ist.

Für die Lösung mit dem Iteratoren-Paar begin/end gibt es zwei Gründe.
1.) Mit dem Iteratoren-Paar kann man nicht nur vom aktuellen Stand bis zum Ende eines Containers laufen sondern über ein beliebiges (halboffenes) Intervall [a,b). Also wenn ein Iteratoren-Paar a,b vorliegt, wobei b von a aus durch eine endliche Folge von Inkrementierungen erreichbar ist, kann man diese als Input für z.B. einen Algorithmus benutzen.
2.) In C++ sollen Iteratoren mit Pointern kompatibel sein. Da man einem Pointer nicht ansehen kann, ob er auf das Ende eines Containers zeigt, hat man die Lösung mit dem Vergleich auf end gewählt.

Gruß
Werner

@Werner Salomon:
3) Ein Output-Iterator braucht z.B. garkeine Ende/Limit zu haben.

@all:
Ich würde die Iteratoren von Java eher "Enumerator" nennen statt Iterator. Dann riecht es auch gleich weniger nach Vermischung von Aufgaben.

@lettort:
Um was gehts jetzt eigentlich noch? Dass diese Sache in der C++ Standard-Lib anders gelöst wurde als in der Java Standard-Lib wissen nun ja alle. Dass C++ Iteratoren bis auf die zwei Sonderfälle "will nur ein Objekt übergeben" und "will Objekt aus der Collection entfernen ohne zu wissen wo die Collection ist" mächtiger sind sollte auch klar sein (*hust*, *duck*). Dafür halt auch komplizierter.

C++ ist eben nicht Java, und Java ist nicht der Weisheit letzter Schluss. Wenn du mich fragst ist Java zwar näher an einer wirklich brauchbaren Sprache für grosse Projekte (die nicht unbedingt Hardwarenahe oder Realtime sein müssen), aber es gibt doch einige Dinge die doof sind. Gerade in der Standard-Lib.

Es hindert dich aber niemand daran für deine Projekte einen (relativ) einfachen Adapter zu schreiben (z.B. Template<DatenTyp> Klasse mit Template<IteratorTyp> Konstruktor) der a) unabhängig vom Container-Typ verwendbar ist und b) eine "hasNext" Funktion implementiert. Wenn du das in einem C++ Projekt machst wo noch andere C++ Programmierer mitarbeiten mach dich aber schonmal darauf gefasst u.U. einige Hate-Mails zu bekommen

Shade Of Mine

Plotzenhotz schrieb:

"will Objekt aus der Collection entfernen ohne zu wissen wo die Collection ist"

*hust* UnsupportedOperationException *hust*

Ja, das kommt noch dazu, UnsupportedOperationException statt grosser/tiefer Interface-Hierarchien ist halt typisch Java-Style (tm) *hust-hust*.

Aber was Programmierfehler angeht die man erst zur Laufzeit merkt ... das kann C++ auch sehr gut *hüstel*.

Shade Of Mine

Plotzenhotz schrieb:

Aber was Programmierfehler angeht die man erst zur Laufzeit merkt ... das kann C++ auch sehr gut *hüstel*.

Ne, ne. Da verstehst du was falsch.

Die Programmierfehler findet man in C++ nicht zur "Laufzeit" sondern zur "nachdem-die-software-verkauft-wurde"-Zeit

Hihi, ja, das auch. @OP: Sorry wegen OT im übrigen.

Simon2

DEvent schrieb:

...In Java ist halt ein anderes Container-Konzept als in der STL.

Für it+=3 kannst du gleich vector.get(i*3) verwenden, RandomAccess ist sowieso nur bei Vectors sinnvoll, weniger bei Listen.

Für --it hast du den ListIterator<E>, mit hasPrevious() und previous().

Danke für die Info !!

Gruß,

Simon2.

Simon2

Plotzenhotz schrieb:

...Aber was Programmierfehler angeht die man erst zur Laufzeit merkt ... das kann C++ auch sehr gut *hüstel*.

Dafür kann man on C++ aber Vieles schon zur Compilezeit rausfinden.
(im Konrekten Beispiel bin ich einfach froh, wenn mir der Compiler oftmals schon beim Füllen des Containers sagen kann, dass mein Objekt da nicht reingehört).
Aber nach einer positiv kontroversen Java-Seminar, bin ich kein unversönlicher Java-Ablehner und C++-Befürworter mehr.

Gruß,

Simon2.