AnsiString in Android App

[Alex_ITA01]

und wieder was dazu gelernt, danke

[himitsu]

Und nur weil Emba das geglaubt hat, haben die nun die AnsiStrings versteckt?

Ich hatte fast schon Angst, daß man aufpassen muß, ob es Copy, Pos, Insert, Delete und Co. auch noch gibt, da du ja nur die Stringtypen wiederhergestellt hast.



Ich überlege auch noch, ob ich mich näher mit den neuen NextGen-Integertypen auseinandersetzen sollte und versuch rauszufinden, wie/ob man da noch richtig mit Überläufen rechnen kann.
Find es nicht mehr, aber da scheint es einen neuen Integer-Typen zu geben, der nicht als Zweierkomplement gespeichert wird, sondern wo das höchste Bit nur das Vorzeichen darstellt
und dann auch noch das $ZEROBASEDSTRINGS oder $OLDTYPELAYOUT ... abwärtskompatibler Code wird langsam nicht mehr so einfach, bzw. man muß ständig aufpassen, daß der Code überhaupt noch vorwärtskompatibel ist.

Und weswegen man den Schrott mit dem $LEGACYIFEND erfinden mußte, versteh ich auch nicht.
Wenn man das nicht kaputt gemacht hätte, bzw. wenn die Idioten ihren Code selber richtig geschrieben hätten, dann bräuchte man es nicht, daß man IF mit ENDIF anstatt mit IFEND zumachen kann ,
vorallem da seit 4 Delphi-Versionen das ErrorInsideInsight es immernoch richtig als "falsch" markiert.

[jaenicke]

Zitat von himitsu:

vorallem da seit 4 Delphi-Versionen das ErrorInsideInsight es immernoch richtig als "falsch" markiert.

Ich habe mittlerweile überall $LEGACYIFEND in die IFs eingesetzt, damit die Markierung nicht mehr kommt. Bei Quelltexten, die nicht mit Versionen wie XE kompatibel sein müssen, habe ich es direkt auf die aktuelle Variante gezogen.
In allen Fällen funktioniert Error Insight damit bei mir korrekt.

[Alex_ITA01]

Darf ich mal fragen, was

ZEROBASEDSTRINGS
OLDTYPELAYOUT
LEGACYIFEND

genau machen bzw. bedeuten?

Viele Grüße

[himitsu]

{$OLDTYPELAYOUT ON} hat was mit der Speicherausrichtung der Felder in Records zu tun. Und dann noch das mit dem Sign in Integertypen.
http://docwiki.embarcadero.com/RADSt...e_Datenformate -> siehe Abschnitt "Implizites Packen von Feldern mit einer gemeinsamen Typspezifikation"

{$ZEROBASEDSTRINGS ON}
Da ist das erste Zeichen im String bei S[0] und nicht bei S[1] , welches (das mit der 0) nun der Standard in Android und iOS ist.
Du mußt also aufpassen, wenn du den selben Delphi-Code für Windows verwendest, oder fürs Mobile, da dort die Indize im String nun alle verschoben sind.

{$LEGACYIFEND}
Es war doch mal so, daß {$IFDEF XYZ} {$ENDIF} mit ENDIF endete und {$IF XYZ} {$IFEND} mit IFEND,
aber weil die Programmierer zu doof waren (ja, an vielen Stellen im Delphi-Quellcode ist das auch "falsch"), kann man nun auch IFEND und ENDIF wild verauschen.

Das war mal absichtlich so implementiert, damit man via IFDEF die IF vor den alten Compilern verstecken konnte, welche die ConditionalExpressions nicht kannten, da der Compiler dann einfach das IFDEF bis zum ENDIF bezieht, weil er das IFEND nicht kenn und somit überieht, ohne daß dabei was kaputt geht.

Delphi-Quellcode:

{$IFDEF ConditionalExpressions}
  {$IF CompilerVersion = 21}
    mach was
  {$IFEND}
{$ENDIF}

Wenn der Compiler das $IF nicht kennt, dannwürde er schon beim ersten IFEND stoppen, wenn man Dieses ebenfalls ENDIF genannt hätte. Und beim zweiten ENDIF würde es dann knallen, weil er kein IFDEF dafür mehr Finden würde.

Delphi-Quellcode:

{$IFDEF ConditionalExpressions}
  {$IF CompilerVersion = 21}
    mach was
{$ENDIF}
{$ENDIF}  // peng

In neueren Delphi hat man aber erlaubt, daß $IF ebenfalls mit $ENDIF enden kann.
Der Compiler knallt nun nicht, auch wenn man es syntaktisch falsch schreiben tut.

Aber das ErrorInsight weiß immernoch, daß es eigentlich falsch ist und unterstreicht dieses eigentliche falsche $ENDIF, auch wenn es sich problemlos compilieren lässt.

[Alex_ITA01]

Danke für deine Erklärung.

Zitat:

{$ZEROBASEDSTRINGS ON}
Da ist das erste Zeichen im String bei S[0] und nicht bei S[1] , welches (das mit der 0) nun der Standard in Android und iOS ist.
Du mußt also aufpassen, wenn du den selben Delphi-Code für Windows verwendest, oder fürs Mobile, da dort die Indize im String nun alle verschoben sind.

Gibt es hierzu Informationen, warum man das so für IOS und Android gemacht hat (also mit S[0] als ersten Char anzufangen)?
Wo steht dann die Längeninformation? Oder gibts die nicht mehr?

Viele Grüße

[mkinzler]

Zitat:

Gibt es hierzu Informationen, warum man das so für IOS und Android gemacht hat (also mit S[0] als ersten Char anzufangen)?

Weil das is C so ist. Und die Kompatibilität zu C scheint wichtiger zu sein, als die Kompatibilität zu altem Delphicode.

Zitat:

Wo steht dann die Längeninformation? Oder gibts die nicht mehr?

Die gab es nur bei ShortString (=alter Stringtyp von Turbopascal), seit Delphi ist AnsiString der Standardtyp (Länge nicht auf 256 Zeichen/8 Bit beschränkt und keine feste Länge)

[himitsu]

Angeblich um die nötige "aufwändige" Umrechnung wegzulassen, so einer Sage nach , denn aus der 1 wird ja intern ein 0-Offset im Char-Array.

In anderen Sprachen ist Char 0 auch das Erste.
Im Delphi stammt das davon, daß im ShortString an der 0 das Längenbyte stand und die LongStrings mit der Zählung gleich blieben, obwohl es das Längenbyte "dort" nicht mehr gibt.
Es ist somit wie in den anderen Sprachen und equivalent zu den dynamischen Arrays.


In der aktuellen OH wird der interne Aufbau der Typen ja inzwischen sehr ausführlich erklärt.

[add]
Alter StringType mit Längenbyte
und neuer Stringtyp mit Längeninteger, aber der liegt vor dem Pointer ... ab dem Pointer kommen gleich die Chars, damit es sich direkt in PChar casten lässt.

Siehe OH
http://docwiki.embarcadero.com/RADSt...e_Datenformate

[Alex_ITA01]

Ok Danke. Habe mir auch grad die Seite mit den Datenformaten durchgelesen

[himitsu]

Bei den alten StringFunktionen muß man nun eben aufpassen, kann sich aber über Low und High auch dir "aktuellen" Indize besorgen.

Und die neuen String-Helper arbeiten immer mit dem 0-Index, auch unter Windows.

Delphi-Quellcode:

var
  S: string;

S.Chars(0) = S[Low(S)]
S.Trim = Trim(S)
S.substring(0, 2) = Copy(S, Low(S), 2)