SortedList oder iDictionary in Delphi (ohne .net!)

[Chemiker]

Hallo Berlinermauer,
z.B.:

Delphi-Quellcode:

type
  TmyPointer= ^TmyRecord;
  TmyRecord= Record
    rEintrag1: String;
    rEintrag2: Integer;
  End

;
An die Stringlist hängen:

Delphi-Quellcode:

p1:= @myRec1;
  p2:= @myRec2;
  myRec1.rEintrag1:= 'Das ist der erte Eintrag';
  myRec1.rEintrag2:= 10001;
  myRec2.rEintrag1:= 'Das ist der zweite Eintrag';
  myRec2.rEintrag2:= 20002;
  CobMitObject.Items.AddObject('Item1',TObject(p1));
  CobMitObject.Items.AddObject('Item2',TObject(p2));

Und so auslesen:

Delphi-Quellcode:

 p1:= TmyPointer (CobMitObject.Items.Objects[CobMitObject.ItemIndex]);
   edEintrag1.Text:= p1.rEintrag1;
   edEintrag2.Text:= inttostr(p1.rEintrag2);

Bis bald Chemiker

[rollstuhlfahrer]

Zitat von Berlinermauer:

Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.

Bitte was willst du? Wenn du ein Objekt, was sich in der Liste befindet löschst, ist es auch nicht mehr in der Liste. Und: Es wird keine Fehlermeldung kommen.

Bernhard

[Berlinermauer]

Zitat von rollstuhlfahrer:

Zitat von Berlinermauer:

Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.

Bitte was willst du? Wenn du ein Objekt, was sich in der Liste befindet löschst, ist es auch nicht mehr in der Liste. Und: Es wird keine Fehlermeldung kommen.

Bernhard

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.

Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Das mit dem Record werd ich mir mal angucken @ Chemiker.

Dennoch würde ich gerne wissen wie ich nen Unsigned 64 Bit Int hinbekomme.

Quasi einen Cardinal64, via type müsste das doch irgendwie gehen oder?


Int64 gibt es ja in Delphi aber kein UInt64

MfG

[stahli]

Zitat:

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.
Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Das funktioniert nur, so lange der Speicherbereich nicht überschrieben wurde (und Du entsprechend glück hast).
Die Verfahrensweise ist also auf keinen Fall korrekt.

[xZise]

Moin,

Zitat von Berlinermauer:

[...]Nein, ein Destroy vor dem Erneuten Create, d.h. wenn das Object schon in der String Liste ist, wird es zerstört und neu created. Ich könnte es auch am ende zerstören, aber da ich das object noch anderseitig brauche, geht das nicht.[...]

Mal nicht so abstrakt:
Wenn du sowas hast:

Delphi-Quellcode:

var
  x : THaus;
begin
  x := THaus.Create;
  x.Free;

Dann erstellst du ein Haus und speicherst du Adresse wo das Haus ist in x. Danach nimmst du die Adresse und sagst: Da wo das Haus ist gebe das Frei (= zerstöre es).

Jetzt hast du sowas:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create;
  y := x;
  x.Free;

Dann ist erstmal alles gleich. Aber gleichzeitig kennt y auch die Adresse vom Haus. Das heißt in x und y stehen die gleichen Adressen. Wenn du jetzt aber x.Free; aufrufst, dann wird das Haus was an der Adresse x steht zerstört. Und damit auch das Haus was bei y drin steht, weil beide ja auf die gleiche Adresse zeigen.

Das heißt y und x sind sozusagen gleich und du hast keinen Unterschied. Du könntest sagen: y.maleAn(Grün) und auch das Haus auf das x zeigt ist danach grün.

Und so was ähnliches machst du ja. Nur das y halt in der Liste steht: In der Liste stehen die Adressen aller Häuser, aber leider zerstörst du die meisten Häuser nachdem du sie erzeugt hast.

Was du anstelle machen kannst:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create; // Erstellt Haus 1 und speichert die Adresse in X
  y := x; // Speichert die Adresse die in X steht (= die von Haus 1) in der Adresse Y
  x := THaus.Create; // Erstellt Haus 2 und speichert die Adresse in X (in Y steht aber weiterhin die alte Adresse)
  x.Free; // Gibt das Haus das an der Adresse, die in X steht frei

Hier hast du zwei Häuser die nicht die gleiche Adresse haben. Das heißt das erste Haus steht weiterhin, während das zweite Haus zerstört ist.

Das bezeichnet man als Aliasing bzw. Alias.

Übrigens benutze nicht direkt x.Destroy; sondern x.Free; oder FreeAndNil(x) .

Und wie du das dann mit den freigeben erledigst musst du sehen:
Eventuell bietet dir die Liste an, die Objekte selber freizugeben (.OwnObjects auf true setzen), ansonsten kannst du auch selber eine zweite Liste haben in der alle Elemente drin stehen die auch mit OwnObjects = true die Elemente freigibt.

MfG
Fabian

[Chemiker]

Hallo Berlinermauer,

Dein Vorgehen ist irgendwie nicht so ganz verständlich. Du solltest auf jeden Fall in dem Project-Quelltext die Zeile:


  ReportMemoryLeaksOnShutdown := true; einfügen, damit Du feststellen kannst ob Du bei Deinem Vorgehen nicht Speicherlöcher produzierst.

Zitat:

Ich mache es umgekehrt, ich erstelle ein Objekt, befülle es, schicke es in die StringListe, und lösche das "echte" wieder.

Das ist doch Kontraproduktiv, Du kannst doch einfach, wie xZise es beschreibt das Object an die StringList anhängen.

Zitat:

Die StringList scheint auch nicht nur einen Pointer darauf setzen, sonst hätte es schon geknallt.

Der StringList ist es egal, ob das Object freigegeben worden ist, oder nicht.

Bis bald Chemiker

[Berlinermauer]

Ich glaube wir reden teilweise aneinander vorbei:

Ich möchte, dass der benutzer an einer ComboBox etwas auswählen kann.
Er hat dazu mehrere Sachen zur Auswahl, es wird aber immer nur eins benutzt nie mehrere gleichzeitig.

Was ich bis jetzt hatte: Objekt kreeieren, Methode des Objekts aufrufen, die vollständig füllt, Objekt der Liste zuweisen, Objekt selbst freigeben.

Ist das jetzt falsch, weil theoretisch eine AccessViolation lesen von Adresse XY die falschen Werte gibt da da was anderes steht?

Wie sollte ich es sonst besser machen? Dynamisches Array ist nen bisschen umständig und Speicherverbrauchend oder? (Obwohl, das wird ja dann nach der Auswahl gelöscht)


btw: kennt denn eigentlich keiner nen UINT 64 in Delphi?

[rollstuhlfahrer]

Zitat von Berlinermauer:

btw: kennt denn eigentlich keiner nen UINT 64 in Delphi?

Gibt es nicht. Int64 (also signed 64bit ist das größte was Delphi semi-nativ unterstützt

Zitat von Berlinermauer:

Ich glaube wir reden teilweise aneinander vorbei:

JA

Zitat von Berlinermauer:

Was ich bis jetzt hatte: Objekt kreeieren, Methode des Objekts aufrufen, die vollständig füllt, Objekt der Liste zuweisen, Objekt selbst freigeben.

Dein Freigeben kommt an der falschen Stelle. Nimm bitte an, dass wenn du das Objekt freigibt, dass dann die Objekte in deiner Liste auch futsch sind. Es ist so!
Der Grund, warum du immernoch auf die gelöschten Objekte zugreifen kannst, ist, dass sie noch im Speicher liegen. Sobald dieser Speicherbereich neu belegt wird, sind die Objekte aber wirklich futsch.

Zitat von Berlinermauer:

Ist das jetzt falsch, weil theoretisch eine AccessViolation lesen von Adresse XY die falschen Werte gibt da da was anderes steht?

Wo kommt denn die AV?

Zitat von Berlinermauer:

Wie sollte ich es sonst besser machen?

Du hast doch eine "funktionierende" Lösung. Was "besseres" gibt es für diesen Anforderungsbrereich nicht (Außer Record).

Bernhard

[xZise]

Moin,
also ich weiß nicht was du vor hast, aber sowas geht nicht:

Delphi-Quellcode:

var
  x, y : THaus;
begin
  x := THaus.Create;
  y := x;
  x.Free;
  y.maleAn(Grün);

Weil sobald du x.Free aufrufst ist auch das Haus y zerstört.

Du hast jetzt folgendes gemacht: Du hast eine Combobox befüllt. Und die Objekte dabei schon freigegeben. Und da man erst nach der Aktion was auswählen kann, sind also alle Objekte bis auf das letzte freigegeben.

Was solltest du anstelle machen? Das habe ich schon gesagt: Mach dir eine TObjectList in der du die Element auch speicherst, und sobald du sie nicht mehr brauchst kannst du sie alle löschen indem du TObjectList.Clear aufrufst (oder die Liste freigibst). Das setzt voraus das OwnObjects auf true steht.

Eventuell kannst du aber auch OwnObjects auf true stellen, von der Liste der ComboBox.

MfG
Fabian

PS: Und falls du glaubst du gibst zu wenig Objekte frei: Schalte doch einfach ReportMemoryLeaksOnShutdown := true; .

[rollstuhlfahrer]

Wenn Delphi 7 stimmt, dann gibt es diesen Schalter nicht. Aber man kann auf für Delphi 7 FastMM einbinden.

Bernhard