Copy AnsiString unter Android fehlerhaft

[skoschke]

Hallo,

ich habe ein komisches Phänomen:
(Code stilisiert...)

Delphi-Quellcode:

var
smlrohdaten, daten1, daten2: AnsiString;
begin
daten1 := copy(smlrohdaten, 1, 100);
daten2 := copy(smlrohdaten, 2, 100);
...

schaut man dann in die Daten, zeigt sich folgendes Bild:
smlrohdaten : 20 1b 1b 1b 1b 01 01 01 01 76 ...
daten1 : 20 1b 1b 1b 1b 01 01 01 01 76 ...
daten2 : 20 1b 1b 1b 1b 01 01 01 01 76 ...

Es wird scheinbar alles kopiert und der Startpunkt ignoriert!
Als Windoes Anwending compiliert funktioniert das Copy!

Was ist denn da nun wieder los?

Ciao
Stefan

[Commander Tom]

Ist es Absicht, dass Du im Quelltext zweimal daten1 verwendest, aber unten bei der Ausgabe daten 1 und daten 2 ausgibst?

[skoschke]

Vertipper, habe es korrigiert

Ciao
Stefan

[Stevie]

Zitat:

Zitat von skoschke (Beitrag 1519649)

schaut man dann in die Daten

Wo? Im Debugger? Im Zweifel falsche Anzeige.
Wenn ich das richtig überblicke wird da _LStrCopy aufgerufen, was wiederum _LStrFromPCharLen aufruft, und die beiden Routinen sind sicherlich nicht in einem solchen Ausmaße defekt.

[Rolf Frei]

Du kopierst da eine uninitilisierte AnsiString Variable oder wo und wie wird smlrohdaten abgefüllt? Wie schaust du dir dann die Daten der Variblen an? Wäre es nicht klüger anstelle von AnsiString TBytes zu nutzen?

[Bernhard Geyer]

Wieso überhaupt AnsiString?

Ich hatte früher auch mal (D1) AnsiString als "ByteBuffer" genutzt, jedoch dann bei Problemen nach Update auf neuer
Delphis (welche schienbar öfter mal auch ein $00 im String "erkannten" dann korrekt auf einen Memory-Stream/ByteArray umgestellt.

[AuronTLG]

Was mir erstmal auffällt sind die String-Indices, falls diese nicht einfach nur dem Beispiel geschuldet sind.
Auf den mobilen Plattformen fangen Strings nicht unbedingt bei 1 an, weswegen man diese nicht hardcoden sondern stattdessen mit Low und High arbeiten sollte.

[himitsu]

Anfangs wurde String/AnsiString genutzt, weil man damit "einfach" arbeiten konnte.

Heute wäre es besser wenigstens den RawByteString zu benutzen,
aber ja, TBytes bzw. TArray<Byte> oder ein Stream wäre für binäre Daten besser geeignet,
vor allem seit sich auch dynamische Arrays string-like behandeln lassen.

Insert/Delete/Copy, aber auch

Delphi-Quellcode:

+

kann man ja inzwischen benutzen.





Lange hatte ich aber auch Strings benutzt, da dynamische Arrays leider kein Copy-on-Write besitzen.

Delphi-Quellcode:

str[123] := 'x';  // #$78
arr[123] := $78;

Mehrere Variablen auf den String, da wird beim String automatisch kopiert
und somit nur diese Variable verändert,
während man beim Array ein Unicuqe selbst herbeiführen muß,
da sonst auch alle anderen Variablen ihren Wert ändern. (zeigen ja alle weiterhin auf den selben Speicher)

Dank der Custom-Managed-Records gibt es aber auch dafür endlich eine Lösung.