P9: Kettung

yourmaninamsterdam
Nerd
Nerd
Beiträge: 681
Registriert: 26. Okt 2006 14:04
Kontaktdaten:

Beitrag von yourmaninamsterdam »

Exactly...

Alexis1987
Windoof-User
Windoof-User
Beiträge: 41
Registriert: 29. Apr 2007 16:58

Beitrag von Alexis1987 »

@Christoph
Danke, jetzt bin ich schlauer. Hatte genau das gleich (meine Typcast) auch ausprobiert allerdings war ich zu blind um zu sehen das die Funktion wirklich angeboten wird, außerdem schreckten mich die Type safety warnings ab.

Also ich nehme alles zurück und behaupte das Gegenteil.
Benutzt Interfaces, huldigt ihnen und opfert ihnen euer Erstgeborenes. ;)

Gruß Alexis
Der Tofu-Burger schmeckt ausgezeichnet, wenn man ihn Kurz vor dem Verzehr durch ein saftiges T-Bone-Steak austauscht.

yourmaninamsterdam
Nerd
Nerd
Beiträge: 681
Registriert: 26. Okt 2006 14:04
Kontaktdaten:

Beitrag von yourmaninamsterdam »

Das Type Safety Warning kommt, weil der Compiler nicht garanieren kann, dass das IHashObject, das du da castest, tatsächlich ein T ist.
Du weißt es aber, deswegen ist das unproblematisch.
Wenn du z.B. ArrayLists benutzt, findet genau so ein "unsicherer" Cast statt, nur innerhalb der ArrayList, deswegen kriegst du die Warnings nicht.

Man kann die Warnings ausblenden, indem man der Methode die Annotation @SuppressWarnings("unchecked") verpasst.

Benutzeravatar
vwm
Mausschubser
Mausschubser
Beiträge: 94
Registriert: 7. Mai 2007 09:42
Wohnort: Rodenbach

Beitrag von vwm »

Apropos Kettung!

Im Prinzip kann man eine Hashtabelle ja auch vollkommen Kettungsfrei und mit Markierungen für gelöschte Elemente implementieren.
Ist das hier erlaubt, oder ist man gezwungen, Verkettungen aufzubauen?
Und, wenn ja: Wie steht es um den Fall, dass ein Schlüssel nach einer Primärkollision eingefügt werden kann, sein Kollisionspartner aber bereits einen Nachfolger hat? Bekommt der Kollisionspartner dann einen weiteren Nachfolger? Geht man beim Löschen dann sämtliche Elemente und deren Nachfolger durch, die jemals mit dem zu löschenden Element kollidiert sind?
Ich tendiere aufgrund dieser Problematik eher zur simplen Variante...
Java löst das ganze ja elegant, indem es die Elemente einfach in sich mit Zeigern verkettet, ohne sie in der Tabelle selbst zu speichern. Das sorgt dafür, dass zwei Elemente aus verschiedenen Kollisionsklassen nicht kollidieren können, aber ist als Idee für dieses Praktikum ja außen vor.
Verkettung mit linearer Sondierung hingegen ist an sich ja unproblematisch zu realisieren, aber die Möglichkeit fällt dank der vorgegebenen Funktionen ja auch weg.
Anregungen? Kommentare?

EDIT: Ah, ich sehe gerade, dass sich so ziemlich in jedem anderen Thread darüber ausgelassen wurde. Dann nehme ich mal an, dass die simple Varainte erlaubt is.

Benutzeravatar
MisterD123
Geek
Geek
Beiträge: 811
Registriert: 31. Okt 2006 20:04
Wohnort: Weiterstadt

Beitrag von MisterD123 »

ich hab passed ohne kettung, also ist definitiv erlaubt ;P

baerchen
Computerversteher
Computerversteher
Beiträge: 382
Registriert: 24. Okt 2006 15:42

Beitrag von baerchen »

wahrscheinlich hat man sogar passed wenn man die sourcen von java.util.Hashtable einschickt. das ist mit sicherheit nicht erlaubt, is von daher kein argument :)
We can do this the hard way or my way ...which is basically the same thing!

HolgerF
Sonntagsinformatiker
Sonntagsinformatiker
Beiträge: 263
Registriert: 16. Jan 2007 14:20
Kontaktdaten:

Beitrag von HolgerF »

Nein, das würde nicht funktionieren, weil die Java-Hashtable, wie vwm schon richtig bemerkt hat, kein Open Addressing benutzt, folglich auch keine Kollisionsfunktion und damit die speziellen Tests hier bestimmt nicht bestehen würde ;)
Ohne Kettung besteht man jedenfalls die Tests auch, und es ist nirgends vorgeschrieben, dass du Kettung verwenden musst, also...

Antworten

Zurück zu „Archiv“