AnsiString in Android App

[Alex_ITA01]

Hallo zusammen,
Ansistring gibt es ja in Android Apps nicht.
Wenn ich dies aber zwingend benötige (da ich mit nicht Unicode Strings -> also 1 Byte für 1 Char) arbeite, brauche ich das natürlich.
Ich habe dies hier gefunden:
http://www.delphifeeds.com/go/f/1111...hiFeeds.com%29

Soll ich das einfach einbinden und dann kann ich meine Variablen als Ansistring deklarieren?
Nachwirkungen oder irgendwelche anderen Probleme habe ich dadurch nicht oder?

Grüße

[himitsu]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1272781)

Soll ich das einfach einbinden und dann kann ich meine Variablen als Ansistring deklarieren?

Laut Beschreibung würde ich Ja sagen.

Zitat:

Zitat von Alex_ITA01 (Beitrag 1272781)

Nachwirkungen oder irgendwelche anderen Probleme habe ich dadurch nicht oder?

Nja, es ist von Andy ... Wer würde da mit großen Nebenwirkungen rechnen? :lol:


Oder du verwendest einfach ein Byte-Array, wenn du eine Reihe von "1" Bytes benötigst. :stupid:

[mkinzler]

Zitat:

Nja, es ist von Andy ... Wer würde da mit großen Nebenwirkungen rechnen?

Es ist nicht so, dass der nextgen compiler keine AnsiStrings könnte; die Funktionalität ist nur "versteckt" und Andy macht diese wieder nutzbar. Fehler wären also ihn nicht zurechenbar.

[Alex_ITA01]

Ah ok. Wieso versteckt man das?
Habe es übrigens getestet, geht ;-)

[Bernhard Geyer]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1272821)

Ah ok. Wieso versteckt man das?
Habe es übrigens getestet, geht ;-)

Weil es schwieriger ist 10 verschiedene Stringtypen auf neue Plattformen zu Portieren als nur noch eine.

Brauchst du wirklich AnsiString? Oder willst du das nur als Bytebuffer mißbrauchen?

[Alex_ITA01]

Ja ich brauche wirklich ein AnsiString.

Wie kommt man denn darauf diese System.ByteStrings im Hexeditor zu ändern?
Also woher kommt die Ursprungsdatei denn? Im XE7 ist die ja nicht enthalten.
Wie kommt man auf solche Sachen? ;-)

[Bernhard Geyer]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1272823)

Ja ich brauche wirklich ein AnsiString

Wieso? Ich denke das unter Android die meisten Apis Unicode-Enabled sind. Die Java-Apis sowieso

[himitsu]

TEncoding kann den AnsiString von Bytes in Unicode umwandeln und beim Speichern kann man es wieder zu ANSI machen.
TStringList, TFile.ReadXXX, TStringStream, TFileStream+TBinaryReader uvm. können auch Ansi einlesen und dann in Unicode umwandeln.

Und wenn es wirklich ANSI bleiben muß, dann liest man es eben als TBytes ein und wandelt es nicht um.

[Alex_ITA01]

Ich gucke mir das mit den TBytes mal an, vielleicht kann ich ja wirklich darauf umsteigen.

Trotzdem nochmal so gefragt:

Wie kommt man denn darauf diese System.ByteStrings im Hexeditor zu ändern?
Also woher kommt die Ursprungsdatei denn? Im XE7 ist die ja nicht enthalten.
Wie kommt man auf solche Sachen?

Grüße

[jbg]

Zitat:

Zitat von Alex_ITA01 (Beitrag 1272830)

Also woher kommt die Ursprungsdatei denn?

Die Ursprungsdatei liegt auf meiner Festplatte und sie so aus.

Delphi-Quellcode:

unit System.ByteStrings;

interface

{$IFDEF NEXTGEN}
type
  ShortString = _ShortString;

  AnsiString = _AnsiString;
  AnsiChar = _AnsiChar;
  PAnsiChar = _PAnsiChar;
  PPAnsiChar = _PPAnsiChar;

  UTF8String = _UTF8String;
  PUTF8String = _PUTF8String;

  RawByteString = _RawByteString;
  PRawByteString = _PRawByteString;
{$ENDIF NEXTGEN}

implementation

end.

Diese lässt sich aber so nicht kompilieren, da die Symbole in der System.dcu nicht mit Unterstrich anfangen, sondern mit "@" (der Compiler ändert alle führenden Unterstriche in System.pas zu "@" ab). Der Patch besteht nun darin, die System.dcu Datei etwas zu recht zu biegen, System.ByteStrings zu kompilieren und danach die System.ByteStrings Unit auf "@" zu patchen.
Es ginge natürlich auch noch einfacher, in dem man die System.pas ändert und neu kompiliert. Aber dann hat man mit Packages und Unit-Abhängigkeiten so seine Probleme.

Zitat:

Wie kommt man auf solche Sachen?

Durch so falsche Aussagen, wie "der Nextgen-Compiler kann nur UnicodeStrings, die anderen Stringtypen werden nicht auf ARM Prozessoren unterstützt". Ein Stringtyp hat mal überhaupt nichts mit dem Prozessor zu tun. Zudem wurden die anderen Stringtypen nur versteckt, ihre Funktionalität ist aber voll gewährleistet (alle Compiler-Magic Funktionen sind vorhanden) und wurde weder von XE3, XE4, XE5, XE6 noch XE7 entfernt.

[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. :wall:
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 :wall:,
vorallem da seit 4 Delphi-Versionen das ErrorInsideInsight es immernoch richtig als "falsch" markiert. :roll:

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1272838)

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

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]

Delphi-Quellcode:

{$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"

Delphi-Quellcode:

{$ZEROBASEDSTRINGS ON}

Da ist das erste Zeichen im String bei

Delphi-Quellcode:

S[0]

und nicht bei

Delphi-Quellcode:

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.

Delphi-Quellcode:

{$LEGACYIFEND}

Es war doch mal so, daß

Delphi-Quellcode:

{$IFDEF XYZ} {$ENDIF}

mit ENDIF endete und

Delphi-Quellcode:

{$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 :roll:, 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. :thumb:

[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 :thumb:

[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)

[Bernhard Geyer]

Zitat:

Zitat von himitsu (Beitrag 1272960)

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)

Am bestesn gleich auf diese Umstellen und Uraltkompatiblität mit Delphi 6/7 aufgeben.
Dann ist es auch einfacher Code von Java/.NET zu lesen und portieren zu können da dort das ja fast Identisch gemacht wird.

[himitsu]

Wenn man es endlich mal hinbekommen könnte, daß man mehr als nur einen Helper benutzen kann, dann würde sich es bestimmt noch mehr verbreiten und würde viele Vorteile bringen, vorallem bei Ausnutzung der Autovervollsändigung.
z.B. "mal gucken was ich alles mit meinem String Typen machen kann"

[himitsu]

Zitat:

Zitat von jbg (Beitrag 1272833)

Zitat:

Wie kommt man auf solche Sachen?

Durch so falsche Aussagen, wie "der Nextgen-Compiler kann nur UnicodeStrings, die anderen Stringtypen werden nicht auf ARM Prozessoren unterstützt". Ein Stringtyp hat mal überhaupt nichts mit dem Prozessor zu tun. Zudem wurden die anderen Stringtypen nur versteckt, ihre Funktionalität ist aber voll gewährleistet (alle Compiler-Magic Funktionen sind vorhanden) und wurde weder von XE3, XE4, XE5, XE6 noch XE7 entfernt.

Die können das auch garnicht so schnell ausbauen, da sie intern an Vielen Stellen immernoch AnsiStrings verwenden, also z.B. bei den alten Dateifunktionen (WriteLn) und wo ich vorgestern wieder mal entnervt drübergestolpert bin, der sLineBreak.
In Windows ist das ein _AnsiString und im NextGen ein _AnsiChar.

Echt geil, da ich per Pointer auf den Text zugreifen und ihn als UnicodeString/WideChar in einen Puffer kopieren wollte.
War fast 'ne ganze Bildschirmseite voll, nur um einen Zeilenumbruch mit paar Leerzeichen zusammenzukopieren. :wall: (jetzt auf wenige Zeilen gekürzt, da ich mir den Dreck nun zu Beginn von Delphi in einen UnicodeString casten lasse)


PS: Kann es sein, daß du deine Webseite aufgeräumt hast?



Ach ja, wer unbedingt einen PAnsiChar braucht, kann auch den MarshaledAString aus der System.pas nehmen. ("aktuell" ist das ein PAnsiChar, denn auch Android benutzt intern AnsiStrings)

Ich würde gern mal wissen, wie Emba seine uOSUtils kompiliert ... haben die sich da was von dir abgeguckt? :stupid:

[jbg]

Zitat:

Zitat von himitsu (Beitrag 1298981)

PS: Kann es sein, daß du deine Webseite aufgeräumt hast?

In welcher Hinsicht?

[himitsu]

Irgendwie führen die bisher gefundenen Links und auch die SuFu auf deiner Seite nicht zu dem Artikel, der diesem ANSI-Spaß gewidmet war.

[jbg]

Also wenn ich auf meiner Seite nach "ANSI" suche, dann taucht da auch Byte-Strings for XE8’s mobile compilers auf.

[himitsu]

Hmmm, sieht genauso aus, wie ich ihn in Erinnerung hab :shock:

Gib's zu, du hast den schnell wieder hochgeladen.
Es liegt aber garantiert nicht daran, daß die Autovervollständigung mir beim jetzigen Versuch ein ansisting vorschlägt.

Der Link im Post #1 und zwei Andere aus Google führten vorhin zu einem "Not Found" :gruebel: