Delphi-PRAXiS

Delphi-PRAXiS (https://www.delphipraxis.net/forum.php)
-   Programmieren allgemein (https://www.delphipraxis.net/40-programmieren-allgemein/)
-   -   Wie sollte sich folgender Iterator verhalten? (https://www.delphipraxis.net/46481-wie-sollte-sich-folgender-iterator-verhalten.html)

Olli 25. Mai 2005 15:10


Wie sollte sich folgender Iterator verhalten?
 
Hi,

ich habe eine Klasse, welche ein Molekül darstellt. Diese Klasse ist gleichzeitig Container für Atome und Bindungen (und Ringe). Nun habe ich teilweise einen Iterator implementiert welcher gültige Elemente aus meinem Container zurückgibt. Der Container kann auch ungültige Elemente enthalten ("sparse matrix", quasi ;) ...), die fürs Rendern aber nicht relevant sind. Also sollen nur gültige zurückgegeben werden.

Nun besteht aber noch die Möglichkeit während der Iteration die Elemente des Containers zu modifizieren, was nicht das Problem ist. Nun aber zum Problem:

Wenn etwas modifiziert wurde, sollte jeder alte Iterator dann ungültig werden oder nicht? Also soll ich einfach vom letzten Punkt innerhalb meiner internen Matrix fortfahren oder lieber eine Exception werfen und so den Benutzer zwingen eine neue Iteration zu beginnen? Im schlechtesten Fall könnte dieser Zwang zu einer Endlosschleife werden.

Robert_G 25. Mai 2005 15:13

Re: Wie sollte sich folgender Iterator verhalten?
 
In .Net ist es allgemeine Praxis es zuzulassen, eine Exception zu werfen oder die Collection auf auf readonly zu setzen. (Letzter Fall ist aber schon ziemlich krass...)
Wenn ich ohne Doku vor einer fremden Collection sitzen würde, würde ich erwarten, dass ich eine Exception bekomme. ;)

weltaran 25. Mai 2005 15:15

Re: Wie sollte sich folgender Iterator verhalten?
 
Entweder du hast nur fähige Benutzer deines Iterators (nur du selbst ;-)), die wissen dass man einen reset machen muss wenn irgendwas modifiziert wird, oder du musst tatsächlich eine Exception werfen (wenn du den Code für andere zur Verfügung stellst.

Ciao

Olli 25. Mai 2005 16:54

Re: Wie sollte sich folgender Iterator verhalten?
 
Zitat:

Zitat von Robert_G
In .Net ist es allgemeine Praxis es zuzulassen, eine Exception zu werfen oder die Collection auf auf readonly zu setzen. (Letzter Fall ist aber schon ziemlich krass...)
Wenn ich ohne Doku vor einer fremden Collection sitzen würde, würde ich erwarten, dass ich eine Exception bekomme. ;)

Bin nicht sicher ob ich es richtig verstanden habe. Guck mal wie ich es meine. Sagen wir vorher gaebe es diese Matrix (o=ungueltig, X=gueltig):
Code:
oXoXXXooooXX
[color=green]o[/color]XoXoXoo[color=red]o[/color]oXo
oXoXooooooXo
oooXooooooXo
Jetzt nehmen wir weiterhin an, dass an der rot markierten Stelle der Iterator halt gemacht hat, waehrend an der gruen markierten Stelle ein Element eingefuegt wird. Ergebnis waere folgendes:
Code:
[color=blue]X[/color]XoXXXooooXX
[color=blue]X[/color]XoXoXoo[color=red]o[/color]oXo
oXoXooooooXo
oooXooooooXo
Da der Iterator per-definitionem bei mir zeilenweise durchgeht, wuerde er beim neu eingefuegten Element (bzw. da eine Spalte immer bis zum hoechsten bisher benutzten Index aufgefuellt wird, Elementen - blau) nie mehr vorbeikommen. Diese wuerde der Benutzer also nie waehrend dieser Iteration sehen.

Das ist zwar hypothetisch, aber ich will zumindest ein definiertes Verhalten.

Zitat:

Zitat von weltaran
Entweder du hast nur fähige Benutzer deines Iterators (nur du selbst ;-)), die wissen dass man einen reset machen muss wenn irgendwas modifiziert wird, oder du musst tatsächlich eine Exception werfen (wenn du den Code für andere zur Verfügung stellst.

Der Code wird potentiell spaeter von anderen gepflegt. Daher muss es ein klar definiertes Verhalten geben ;)
Wird aber auch dokumentiert, falls du darauf hinaus wolltest.

Robert_G 25. Mai 2005 17:35

Re: Wie sollte sich folgender Iterator verhalten?
 
Wohldefiniert und simpel implemenitiert wäre es in deinem Fall, die Collection zu sperren.
Als Lösung für konsistente gleichzeitige Zugriffe fallen mir nur Transaktionen ein. :gruebel:
Dumm ist nur, dass dir das tierisch Performance kosten kann. Falls es viele Daten werden willst du ja ganz bestimmt keine Copy im Speicher halten. Jage mich mit Bennenungen für allgemeine Patterns, aber eine Art "copy on write demand" wäre hier vielleicht möglich.
Du könntest jedem Zugriff eine Transaktion verpassen, solange nichts geändert wurde wird sie mit einem einfachen Zeiger auf die bestehenden Daten arbeiten. Bei einer Änderung müsstest du die Daten des betroffenen Segmentes kopieren und fortan wird eine Abfrage auf das Segment mit deiner Transaktionsnummer die Kopie zeigen. Wie fein du deine Daten in einzelne Segmente einteilst musst du austesten, aber wenn es viele Daten werden sollte die Aufteilung nicht zu klein werden. Sonst würden die die ständigen Abfragen die Zyklen wegfressen...
Ich hoffe ich konnte mich in der Kürze irgendwie verständich machen... :freak: Da ich gerade in einer bösen Server Validierung stecke komme ich wohl in den nächsten Stunden nicht mehr zu einer größeren "DP Pause". :pale:

Mit etwas Glück, habe ich dich falsch verstanden... :mrgreen:

Olli 26. Mai 2005 12:18

Re: Wie sollte sich folgender Iterator verhalten?
 
Performance ist hier nicht so wichtig. Die eigentlichen Berechnungen finden nach der Transformation in andere Matrizen statt. Die Moleküle werden aus XML-Files geladen und dann angezeigt, wobei das anzeigen aus der schon eingelesenen Struktur heraus geschieht. Das ist also nichts zeitkritisches.

Das mit der Transaktion ist auch nicht so einfach, weil ich ja nicht überprüfen kann ob ein Objekt geändert wurde (denn ein Molekül besteht bei mir aus Atomen und Bindungen - 4 Bindungen und 2 Atome sind wiederum in einer Sammelstruktur verwaltet, die ich in der o.g. Matrix zusammenfasse - diese Sammelstruktur bekommt der Benutzer nie zu Gesicht!), es sei denn ich nähme vor der Transaktion eine Kopie (was dann wirklich zuviel Overhead würde).

Danke erstmal für eure Hinweise!


Alle Zeitangaben in WEZ +1. Es ist jetzt 03:03 Uhr.

Powered by vBulletin® Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.
LinkBacks Enabled by vBSEO © 2011, Crawlability, Inc.
Delphi-PRAXiS (c) 2002 - 2023 by Daniel R. Wolf, 2024 by Thomas Breitkreuz