@ Operator bei dynamischem Array

[mbruegel]

Beim Versuch einProgramm von Delphi nach FPC bin ich auf folgendes Problem gestoßen.
Evtl. kennt das ja jemand

Code: Alles auswählen

TYPE
TXY = RECORD
X,Y LONGINT;
END;
TArrXY = ARRAY OF TXY;
FUNCTION TGDSstream.GetXY : TArrXY;
BEGIN 
SetLength(GetXY,Anz DIV8);
gzread(GDSFILE,@GetXY[0],Anz);
END;

Funktioniert nicht! in Delphi aber schon.

Habe dann herausgefunden dass

@Getxy[0] <> @GetXY ist.

Eigentlich hätte ich erwartet das das gleich ist. Ist es aber nicht. Und zwar sind die Adressen ganz anders in einem ganz anderen Bereich.

Kann das jemand erklären

[MAC]

was genau funktioniert da bitte nicht, fehlermeldung.

was willst du machen ?

willst du das machen
funktioniert das

Code: Alles auswählen

TYPE
 
TXY = RECORD
X,Y LONGINT;
END;
 
TArrXY = record
z:ARRAY OF TXY; // geändert
end;
 
FUNCTION TGDSstream.GetXY : TArrXY;
BEGIN
SetLength(result.z,Anz DIV8);         // geändert
gzread(GDSFILE,@result.z[0],Anz);  // geändert
END;

[mbruegel]

Code: Alles auswählen

TYPE
TXY = RECORD
           X,Y : LONGINT;
         END;
 
TArrXY = ARRAY OF TXY; 
 
....
 
FUNCTION TGDSstream.GetXY : TArrXY;
BEGIN
  SetLength(Result,Anz DIV 8);
  gzread(GDSFILE,@result[0],Anz);
END;

OK, so sollte es sein.
In das dynamische Array (Result) Ergebnis der Funktion sollten Koordinaten aus dem stream gelesen werden.
gzread benötigt dazu die Adresse des Speichers in welche die Bytes geladen werden sollen.
Das sollte @result[0] liefern.

Die Daten landen aber irgendwo anders, wo weis ich nicht. Offensichtlich ist die Adresse falsch.
Verwende ich ein statisches Array geht das OK. In Delphi ging das auch mit dem dynamischen Array.

[mschnell]

Habe dann herausgefunden dass

@Getxy[0] <> @GetXY ist.

Eigentlich hätte ich erwartet das das gleich ist. Ist es aber nicht. Und zwar sind die Adressen ganz anders in einem ganz anderen Bereich.

Ein Dynamisches Array hat einen Verwaltungs-Struktur und einen Daten.Berfeich. @GetXY ergibt den Zeiger auf die Verwaltungs-Struktur.

Genauso ist @MyString <> @MyString[1].

-Michael

[mbruegel]

Ja allerdings. Hätte aber erwartet dass @dynArray = @dynArray[0] -8 ist.
Ist aber eine ganz andere Adresse. Das hat mich zuerstmal verwirrt. Trotzdem hätte der Code mit @dynArray[0] funktionieren sollen.

[mbruegel]

OK. Ich nehme alles zurück und behaupte das Gegenteil.

Ich bin über den Lazarus Debugger gestolpert. Der gibt bei mir im Falle von dyn Arrays Müll aus.

Der eigentliche Fehler war eine Variable in einer Klasse, die den gleichen Namen hatte wie der Name einer variablen in einer Methode der Klasse.

z.b,

CLASS C
M : TMatrix
CONSTRUCTOR Create(M : TMatrix)

.....

Der FPC Compiler beschwert sich und ich hatte M in aM geändert.
Allerdings dann an einer Stelle vergessen innerhalb der Methode auch auf aM zu ändern.
Da es M intern gibt, kam es zu keinem Fehler.

Also Fall vergessen und weiter im Text.