Liste (ähnlich dyn Array) mit fortlaufendem Index?

[moelski]

Moin !

Gibts eigentlich eine Liste mit einer Art fortlaufendem Index?

Bsp: In SQL gibts ja den Feldtyp AutoInc. Bedeutet das Feld bekommt immer einen Wert MAX+1 und das unabhängig davon ob ich vorne in der Liste etwas lösche oder nicht. Der Index is immer eindeutig und ich kann damit einen Datensatz eben auch eindeutig identifizieren (u.a.).

Gibt es sowas auch in Delphi als fertiges Objekt? Kann das evtl. TQueue oder TCollection?

Hintergrund:
Ich möchte eine Liste aufbauen die ich dynamisch ergänze. Aus dieser Liste wiederum möchte ich Indexbezogen Daten asynchron auslesen und verarbeiten und dann die Daten aus der Liste löschen.
Wenn ich jetzt z.B. ein dyn. Array dafür verwende, dann habe ich keinen eindeutigen Index auf den ich zugreifen kann, denn durch das löschen verschiebt sich alles immer wieder.
Das Löschen wiederum ist wichtig weil ich die Daten nicht unnötig im Speicher halten möchte.

[mkinzler]

Halte den "Index" als Teil der Daten

[Uwe Raabe]

Bei TCollection haben die Items eine eindeutige ID property, die beim Einfügen in die Collection gesetzt wird. Der Index kann sich ändern, die ID nicht.

[Khabarakh]

So etwas habe ich ehrlich gesagt noch nie gebraucht, schließlich stellt doch der Pointer auf das Objekt selbst schon eine eindeutige ID dar Einziger Unterschied ist, dass die Objekt-Adressen natürlich nicht unbedingt aufsteigend sind.

[himitsu]

Zitat von mkinzler:

Halte den "Index" als Teil der Daten

Genau,

der Index für den Zugriff auf die Daten wäre dann nicht der "Index" der Daten innerhalb der Datenhaltung, sondern der Wert eines Feldes innerhalb der einzelnen Daten.

Beim Zugriff müßten dann nur die Daten mit dem entsprechende Indexwert gesucht werden ... ähnlich .Name bei einer Stringliste.

[Blup]

Warum sollte das Objekt selbst einen festen Index haben?
Wird das Objekt irgendwo referenziert, kann ich dort direkt auf die Felder zugreifen.
Die Position in einer Liste mit IndexOf(Object).
Falls ich wirklich so etwas wie eine ID brauch, dann die Adresse im Speicher Cardinal(Pointer(Object)).
Allerings kann ein neues Objekt dann eventuell die Speicheradresse eines bereits freigegebenen Objektes bekommen.

[moelski]

Moin !

Erstmal danke für die Antworten bis hierher.

Zitat:

Beim Zugriff müßten dann nur die Daten mit dem entsprechende Indexwert gesucht werden

Genau das möchte ich eben vermeiden, das ich in den Daten noch rumsuchen muss.

Ich möchte eben an der Liste Daten anfügen z.B. mit einem Thread. Und parallel dazu möchte ich Teile der Daten auswerten lassen. Dazu wäre es eben sehr praktisch einen fortlaufenden festen Index zu haben. Denn so könnte ich der auswertenden Routine sagen "Bearbeite mal Index 34-103" ohne mir jemals Gedanken machen zu müssen ob diese Index auch wirklich nach dem Start der Bearbeitung weiterhin so existieren.

Denn wie gesagt möchte ich die Bereiche der Liste die bearbeitet worden sind löschen.

Zitat:

Bei TCollection haben die Items eine eindeutige ID property

Da hätte ich aber nicht den Zugriff direkt über einen Index sondern müsste ja letztlich auch suchen. Sicher machbar, aber wie zuvor geschrieben möchte ich Suchen vermeiden aus Performancegründen.

[Tryer]

Ich habe das Problem mal wie folgt gelöst:

Beide Threads ("Sammler" und "Arbeiter") haben je eine TList.
Der Sammler füllt fleissig seine Liste und setzt einen Event über den der Arbeiter erkennt das neue Daten vorliegen (WaitForSingleObject). Dann tauscht er seine abgearbeitete, leere Liste per FWorkList := TList(InterlockedExchange( Integer(FSammler.FList), Integer(FWorkList))); mit dem Sammler aus.
Der Sammler macht immer ein einfaches Add() und der Arbeiter kann von 0 bis Pred(Count) zugreifen ohne das sich die beiden jemals ins Gehege kommen.
Der eindeutige Index ist dann überflüssig.

MfG,
Dirk

[moelski]

Moin Tryer,

das klappt bei mir leider nicht so ganz.
Denn bei mir müssen zwei "worker" aus der Liste lesen - ggf. sogar mehr.

Ich habe es jetzt mal mit TList versucht.
Meine Hoffnung war das ich dort Pointer einhängen kann. Das klappt auch.
Danach habe ich die Einträge der Liste auf NIL gesetzt. Aber es wird kein Speicher freigegeben.
Das passiert vermutlich nur bei Delete.

Hmm scheint so als müsse ich doch einen eigenen Index mitführen.
Das passt mir zwar irgendwie gar nicht weil ich dann suchen muss, aber mal sehen ...

[himitsu]

Zitat:

Genau das möchte ich eben vermeiden, das ich in den Daten noch rumsuchen muss.

Suchen wirst du so oder so müssen, es sei denn du nimmst die ID doch direkt als Index und erzeugst für alle nichtvorhandenen IDs leere Einträge.

Und das Suchen würde natürlich in das "Array"-Objekt integriert.
Halt so ähnlich, als wie es bei StringListe.Name[] gelöst ist.