Arraydaten im Debugger anzeigen

[Kas Ob.]

There is no problem in this screenshots, everything is fine.

That junk is from uninitialized values, eg. when you set the length of an array to lets say 10 then it will receive un-zeroed memory from the memory manager (could be recycled and previously used by something like a TBitmap), so what ever was there it will stay there until been written on, so unless you fill it with data the data inside it will be junk from your prospective but it is just residue.

The Chinese chars are from the junk of data because the uninitialized strings might have a value that land on valid and accessible memory showing arbitrary lengths and content.

To be on safe side you can/should zero such arrays with managed types before start to fill them.

[ManfredU]

Danke für die Rasche Antwort. Ich habe nur im Musterbeispiel vergessen SetLength(array, 0, 0) zu setzten. Trotzdem ist immer noch der gleiche Effekt. Er zeigt immer 254 Zeilen und 254 Spalten an. Wenn ich aber in einer Schleife alle anzeige gibt er die richtige Anzahl Einträge und Inhalte zurück. Auch bei length(array) kommt die richtige Anzahl zurück.
Wieso kann er es für Windows und nicht für Android?
Lg
Manfred

[himitsu]

Zitat von Kas Ob.:

That junk is from uninitialized values

Dynamische Arrays und LongStrings (String, UnicodeString, AnsiString und deren Ableitungen / nicht ShortString) sind immer initialisiert,
so wie es bei allen managed Typen der Fall ist.

Aber es kann sein, dass hier der Compilier diese Variable bereits weg optimiert hat, da dort unten diese Variable nicht mehr benuitzt wird,
und dann die DebugInfos an eine Stelle zeigen, wo kein Array mehr ist, also anderer "Datensalat" dort im Arbeitsspeicher liegt.


Im Windows-Compiler (Win32) wird so eine Variable normaler Weise erst im "end" der Methode freigegeben, aber im Android-Compiler kann es anders aussehen.

[ManfredU]

In Delphi 10.3 war aber die Anzeige aber richtig, wieso dann in 11.3 nicht mehr?
Lg
Manfred

[Kas Ob.]

Zitat von himitsu:

Zitat von Kas Ob.:

That junk is from uninitialized values

Dynamische Arrays und LongStrings (String, UnicodeString, AnsiString und deren Ableitungen / nicht ShortString) sind immer initialisiert,
so wie es bei allen managed Typen der Fall ist..

Thank you and i know that, also saw what Delphi IDE/Compiler can do, please have a look at this code and see why it is crashing on x32 while crashing the debugger itself on x64, on my XE8, so no guarantee on the behavior on newer version though.

Code:

procedure TForm10.FormCreate(Sender: TObject);
var
  a:array of string;
begin
  SetLength(a,4);
  a[0]:='string1';
  a[1]:='string2';
  a[2]:='string3';
  a[3]:='string4';
  SetLength(a,2);
  SetLength(a,4);
  ShowMessage(a[4]);
end;

2023-10-24 18_52_08-Untitled - Paint.png

[Kas Ob.]

Ok that was a bad and unreliable example, it takes many times of running and retrying on x64 to crash the debugger and the content of the array goes junk.

[himitsu]

Der Index 4 muß knallen, da es ja nur 4 Items gibt, also der Größte die 3 ist, wenn man bei 0 anfängt zu zählen.

In aktuellen Delphis sind nun standardmäßig die Überlauf- und Bereichsprüfung aktiviert, für neu erstellte Projekte (leider auch die dämlichen DebugDCUs),
womit dort ein anderer Fehler zu sehen ist, bezüglich der 4:

Zitat:

Im Projekt Project27.exe ist eine Exception der Klasse ERangeError mit der Meldung 'Fehler bei Bereichsprüfung' aufgetreten.

PS:

Delphi-Quellcode:

procedure TForm25.FormCreate(Sender: TObject);
var
  a: array of string;
begin
  a := ['string0', 'string1', 'string2', 'string3'];
  SetLength(a, 2);
  SetLength(a, 4);
  ShowMessage(a[3]);  // High(a) = 3
end;