Danke, so habe ich mir das auch gedacht, bis jetzt war es so dass bei Comparator-Gleichheit und bei Nicht-equals-Gleichheit genau das zuletzt eingefüte Elem eingeführt wurde (Set guarantee). Nach Comparator-Gleichheit gleiche Elems standen nach Mehrfacheingefügt also nicht mehr im Set. Ich muss da noch etwas bei fummeln.der bekommt halt eine ID
Wenn, dann müsstest Du es ja umgekehrt machen: Comparator-Ungleichheit bei equals-Gleichheit. Das Problem ist, dass man nicht weiß, welches Element bei compare(a, b) für a verwendet wird und es sein könnte, dass im Code ja einmal compare(a,b) und einmal compare(b, a) vorkommt.bis jetzt war es so dass bei Comparator-Gleichheit und bei Nicht-equals-Gleichheit genau das zuletzt eingefüte Elem eingeführt wurde (Set guarantee).
Nur weil Du die Umfrage nicht verstehst.was soll hier die blöde Umfrage ?
Ja ich weiß aber gerade nicht wie so ein Beispiel-Code aussehen würde? Hättest du einen Denkanstoß?Wenn, dann müsstest Du es ja umgekehrt machen
Das bricht aber den compare-Contract, daJava:int compare(Object o1, Object o2) { if (o1.equals(o2)) { return -1; } return ... }
compare(o1,o2) == compare(o2,o1)
? (oder war das mit Absicht ein sehr unvollständiges Beispiel?)Ja, das ist das oben angesprochene Problem, dass diese "Lösung" von der Implementierung des TreeSet abhängig ist.Das bricht aber den compare-Contract
Kontrakt? Ich dachte das hieße Konvention.Contract
TreeSet<E[]> tsl = new TreeSet<>((o1, o2) -> {
int p1 = 0;
int p2 = 0;
for (int i = 0; i < o1.length; i += 2) {
p1 += (o1[i + 1].sell_price - o1[i].buy_price);
p2 += (o2[i + 1].sell_price - o2[i].buy_price);
}
if (p1 != p2) {
return Integer.compare(p2, p1);
}
return Integer.compare(o1.hashCode(), o2.hashCode());
});
.hashCode()
auf einem Array aufzurufen. Oder Schnaps? (Obwohl der heutige Tag auf -tag endet!!!! )dann Wrapper
equals()
gar nicht mehr zum Zuge kommt. Denn wenn doch dann müsste bei Comparator-Gleichheit Hashcode-equals()-Gleichheit falsch sein, wonach eingefügt werden SOLLTE.... tuts aber nicht.Vermutlich schon. Kommt halt darauf an, was Du letztlich vorhast; Deine Frage zielte aber explizit auf TreeSet ab.Wärs nicht doch besser alles nicht sortiert in einer listenartigen Struktur anzusammeln und zum Schluss einmal zu sortieren?
Nicht nur bei Deiner Maschine und nicht nur beim Einfügen: für das TreeSet ist dokumentiert, dass ausschließlich ein Comparator zum Einsatz kommt.Bei meiner Maschine ist es so dass zum Bleistift beim Einfügen equals() gar nicht mehr zum Zuge kommt.
TreeSet
zu sortierenden E[]
s nicht die Eigenschaft einer totalen Quasiordnung (reflexiv ,transitiv und total) inne haben? - Oder anders: Besitzen die E[]
s diese nicht bereits?Vertrag ist was anderes als Konvention...Kontrakt? Ich dachte das hieße Konvention.
Durchsuch einfach mal das Javadoc von Comparator nach "contract" und nach "convention"Ich bin mir ganz sicher das das nicht Kontrakt heißt sondern Konvention.... Aber Du wirst ganz bestimmt mehr Rechtsvorlesungen gehört haben als ich, Dich bestens damit auskennen und niemals Lügen verbreiten? Wenn ich etwas nicht weiß dann antworte ich idR nicht (um andere nicht zu stören) Bei Dir scheinbar nicht so.
Wobei das eher ein Whopper istALSO: Doch ein Wrapper.
Schlechtes Beispiel (ganz böse Du heute bist....), es kann immer nur ein Papst gleichzeitig sein.Das machen die Päpste schon lange
Generell ist das auch nicht merkwürdigIch finde es gar nicht so merkwürdig, wenn man gleichen Elementen ein zusätzliches Merkmal spendiert, um sie untereinander unterscheidbar zu machen und ggf. auch noch eine Ordnung darüber zu definieren. Das machen die Päpste schon lange
Nö, hab ich bisher noch nicht gemerkt. (...außer du meinst equals vs compare)@mrBrown Eine TreeSet heißt zwar Set.... aber ist keine ( im eigentlichen Sinne ). Das hast Du bestimmt schon gemerkt.
Nichts, das ist genau richtig. Die Frage ist nur, was die richtige vorhandene Struktur ist, und dafür müsste man wissen, was deine Anforderung ist ("gleiche Elemente in ein TreeSet würde ich jetzt nicht als solche bezeichnen...)Was ist denn so schlecht daran sich vorhandener Strukturen zu bedienen?
Sonst würde ja auch eine ConcurrentPopeException geworfen.es kann immer nur ein Papst gleichzeitig sein.
Nachdem wir sein Problem nicht kennen...die für das Problem ungeeignet ist
Ja gut, aber zumindest klingt hier nichts danach, als wäre ein TreeSet die sinnvollste LösungNachdem wir sein Problem nicht kennen...
@mihe7 Bitte keine Esoterik.ein non-unique Index auf Basis eines Baums unter Beibehaltung der Einfügereihenfolge
vielleicht keine. Viell alternativlos. (Spaß...)Welche Standardklasse gäbe es hierfür außer dem TreeSet noch
Und wenn man die Anforderungen kennen würde, könnte man uU noch eine bessere Alternative vorschlagen@mrBrown Wenn die Anforderungsdefinition man ändern würde, dass diese Collection nicht jederzeit sortiert sein müsste, dann langte auch eine ArrayList.
Jeden Tag, direkt nach dem Aufstehen, spreche ich erstmal mit meinen B-Trees.Bitte keine Esoterik.