Exception beim SetLength für ein Array

[Der schöne Günther]

Ja, welche Exception denn überhaupt wäre sehr interessant.

Ich kenne Lazarus nicht, aber in Delphi lässt man sich oft gerne in die Irre führen dass der Debugger beim Anhalten bei einer Exception im Quelltext eine Zeile zu tief anstreicht, die Exception trat dann in Wirklichkeit eine Zeile darüber auf (dConnections.First; )

[himitsu]

In MessageBoxen/Fehlerdialogen von Delphi-Programmen und hoffentlich auch Lazarus (FCL) funktionirt Strg+C im Dialog
und dann Strg+V im Texteditor hier im Forum, zum kopieren des Textes.


Häufigste Fehler:

> OutOfMemory
Was das wohl sein wird?

> Zugriffsverletzung bei Adresse 00000irgendwas
TConnection.Create vergessen?

Ansonsten entweder ein alter Zeiger (Objekt schon freigegeben)
oder du hast irgendwo einen Buffer-Overflow hast dir dadurch das Speichermanagement des Arrays zerschossen.




PS:
SetLength(Items, dConnections.RecordCount);
Und spaßig wird dein Code, bei über 100000 Records.

Warum TConnectionListe nicht von TList, TList<TConnection>, TDirectory<xxx,TConnection> oder Dergleichen erben lassen?
Wie die Syntax der Generics in Lazarus FreePascal ist, weiß ich nicht, aber sowas gibt es dort ja auch.

[KodeZwerg]

Zitat von himitsu:

Warum TConnectionListe nicht von TList, TList<TConnection>, TDirectory<xxx,TConnection> oder Dergleichen erben lassen?
Wie die Syntax der Generics in Lazarus FreePascal ist, weiß ich nicht, aber sowas gibt es dort ja auch.

Das war auch mein erster Gedanke, aber Du weißt Dich besser auszudrücken.

[nwnssolutionssoftware]

Vielen Dank für die vielen Anregungen...

Kopieren und Einfügen von Fehlermeldungen ist in Lazarus etwas schwierig, deswegen hier mal in abgetippter Variante:

Code:

Projekt XXXXX hat Exception-KLasse >> External:SIGSEGV << ausgelößt. Bei Adresse: 10000ED52

Es könnte durchaus möglich sein das ich vergessen habe das Objekt zu Create´n. Wüsste aber auch nicht spontan wie man sowas richtig macht dachte ein SetLength reicht für ein Array.

Danke im Vorraus

[nwnssolutionssoftware]

Um die 10000 zu erklären es ist relativ unwahrscheinlich das man mehr als 10000 Einträge anlegt. Deswegen habe ich mich dafür entschieden eine feste Grenze festzulegen. Aber klar man könnte es auch mit einem Record Count machen wobei ich da nicht weiß wie sich das bei einem Filter verhält.

Wovon man das Objekt am Ende erben lässt kann man sich auch drüber streiten. Muss aber auch dazu sagen das ist mein erstes Projekt was ich Objektorientiert programmiere, deswegen bin ich natürlich für Vorschläge offen.

[haentschman]

Zitat:

Es könnte durchaus möglich sein das ich vergessen habe das Objekt zu Create´n.

..dann hilft nur den QT hier einstellen. Ganze Unit oder komplett als ZIP.

Wie die anderen schon erwähnt haben:
Besser ist eine Liste für die "Items" Items : TObjectList; Kann Lazarus Generics? ...dann Items : TObjectList<TConnection>;

[himitsu]

Zitat von haentschman:

Kann Lazarus Generics? ...dann Items : TObjectList<TConnection>;

Ja, dort wurde schon vor 'ner Weile auch sowas gebaut.
Aber da es ja eine Eigentwicklung ist ... da ist das dann in FreePascal dann auch öfters auch bissl anders gelöst, bzw. man muß im passenden Modus kompilieren.
https://wiki.freepascal.org/Generics

Normale TList/TObjectList gegenüber generischer TList<T>/TObjectList<T>,
dort ist einfach, dass da der Typcast bereits eingebaut ist und das auch alles durch die Typprüfung des Compilers behandelt wird. (weniger potentielle Fehler)

Delphi-Quellcode:

TConnectionListe = class
  Items : Array of TConnection;
  ...
end;
  
TConnectionListe = class
  Items : TObjectList<TConnection>;  // enthält eine Liste
  ...
end;
// ConnectionListe.Items.Add
  
TConnectionListe = class(TObjectList<TConnection>)  // ist selbst die Liste
  ...
end;
// ConnectionListe.Add

Und natürlich im Destructor nicht vergessen die Items (die vielen TConnection) nicht vergessen freizugeben.
Die ObjectListe hat da den Vorteil das über OwnsObjects automatisch machen zu können.

Außerdem in TConnection.Destroy nicht vergessen das Image freizugeben.

[sakura]

sSIGSEGV -> Speicherzugriffsverletzung. Hast Du evtl. vorher schon etwas mit Items gemacht? Geht es mit deutlich kleineren Werten, z.B. 10 (zum Test).

Ansonsten, ermittele zuerst die Anzahl and lege dann die Länge fest. Oder nutze, noch besser, eine TObjectList, bzw. TList<TConnection>. Wie auch immer, in vielen Situationen arbeitest Du wahrscheinlich mit nicht einmal 10 Objekten, also warum den Speicher so nutzlos verbrauchen? Auch wenn es nur Pointer sind, reden wir am Ende über ein paar MB sinnlos verschwendeten Speichern, wenn Du es des Öfteren so handhabst.

.....

P.S. Wenn Du schon mit 100000 Objekten rechnest, dann kommt irgendwann jemand mit mehr. Ist leider einfach so

P.P.S.: In der Erklärung schreibst Du 10000, im Code sind es 100000. Bist Du Dir sicher, bei der anzunehmenden Menge.

[himitsu]

Im RecordCount wird der DataSet.Filter beachtet, also passt die Anzahl.



Wenn die TConnectionListe vorher nicht erstellt wurde, dann existiert beim Aufruf von Methoden/Eigenschaften das zugehörige Objekt nicht,
also existiert auch das darin enthaltene Items nicht.

Da Items das Einzige ist, was in dem Objekt existiert, knallt es natürlich nur/erst beim Zugriff auf diese Eigenschaft.
Als Self würden nil oder ein ungültiger Zeiger erstmal problemlos an die Methode übergeben.



Das mit dem Objektlist ist einfach:
Du hast dir eine Klasse gebaut, die eine Liste (Array) enthält.
Man kann diese Liste/Array selbst behandeln, oder man erbt von einer Listen-Klasse und kann dann deren Methoden verwenden,
angefangen beim TObjectList.Add, wo intern der Speicher bereits mit einer Optimierung mehr reserviert, bzw. man kann auch manuell List.Capacity:=DS.RecordCount den Wert vorgeben, entsprechend deinem SetLength.