Quo vadis Delphi XE8 ?

[jaenicke]

Zitat:

Zitat von himitsu (Beitrag 1289882)

Auch wenn ich nicht wirklich verstanden hab, warum man das ANSI/UTF-8 abgeschafft hat.

Weil es leider in vielen Fällen ohne Not einfach so benutzt wird. Oft aus Unkenntnis, oft aus Bequemlichkeit. Selbst in zwei Projekten, die Andreas Unit verwenden, wird es offenbar einfach nur verwendet, damit es Ansi ist, obwohl es dort gar keinen Grund dafür gibt. Nur funktioniert die App nur dadurch nicht z.B. mit chinesischer Sprache (ist aber auch nicht im AppStore).

Deshalb kann ich den Schritt durchaus nachvollziehen...

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

[Stevie]

Zitat:

Zitat von jaenicke (Beitrag 1289905)

Es gibt aber natürlich auch seltene Fälle, in denen Ansistrings tatsächlich Sinn machen, auch auf mobilen Plattformen. Zum Beispiel, wenn man mit einem Dienst direkt kommuniziert, der Ansistrings benutzt.

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

[CHackbart]

Wenn jch überlege was für Verrenkungen ich bei Synapse TCP machen musste. Es macht keinen Sinn den Entwickler zu bevormunden. Fast jede Lowlevel API verlangt nach Ansi und da dauernd Verrenkungen einbauen zu müssen ist eher eine Gängelung.

[jaenicke]

Zitat:

Zitat von Stevie (Beitrag 1289906)

Da kann man doch aber problemlos TBytes hin und her ballern und das per TEncoding lösen oder?

Das ist auch der bessere Weg, aber besser ist nicht einfacher und deshalb möchten viele den Weg nicht bestreiten. ;-)

[jbg]

Für mich persönlich wäre es schön, wenn zumindest UTF8String zur Verfügung stehen würde. Auf den ANSI-String kann ich verzichten. Aber UTF8 ist der Quasi-Standard des Internets. Und laufend mit TBytes herumzuhantieren macht da wenig Spaß.

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

[jaenicke]

Da stimme ich zu, mit UTF-8 sieht das anders aus. Ich wandele allerdings immer zuerst in Unicodestrings um, so dass ich aktuell keine Probleme habe.

[Bernhard Geyer]

Zitat:

Zitat von jbg (Beitrag 1289914)

Was sieht wohl leserlicher aus (und nein, ich werden Byte nicht in WideChar konvertieren was ein unnötiges "MOVZX" einfügen würde):

Delphi-Quellcode:

B[I] in [Ord('A')..Ord('Z'), Ord('a')..Ord('z'), Ord('_'), Ord('0')..Ord('9')]
// oder
S[I] in ['A'..'Z', 'a'..'z', '_', '0'..'9']

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

[Bernhard Geyer]

Zitat:

Zitat von jaenicke (Beitrag 1289915)

Da stimme ich zu, mit UTF-8 sieht das anders aus. Ich wandele allerdings immer zuerst in Unicodestrings um, so dass ich aktuell keine Probleme habe.

Man sollte seine Anwendung so gestallten das nur an den "Außenkontaktstellen" in die nötige Charset/Codepage/Codierung gewandelt wird und intern 100% mit UnicodStrings gearbeitet wird.

[jbg]

Zitat:

Zitat von Bernhard Geyer (Beitrag 1289917)

Man sollte seine Anwendung so gestallten das nur an den "Außenkontaktstellen" in die nötige Charset/Codepage/Codierung gewandelt wird und intern 100% mit UnicodStrings gearbeitet wird.

Und was macht ein JSON Parser der UTF8 "on the fly" bekommt? Einfach mal zwischen einer multi-byte UTF8-Sequence in UTF16 konvertieren dürfte interessante Ergebnisse liefern. Am Ende spuckt er schon einen UTF16-"Baum" aus, aber zum Parsen nutzt er UTF8.

Zitat:

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

Pfui. CharInSet ist für einen Parser der letzte Unsinn. Der Compiler generiert für CharSets mit nur ASCII-Zeichen den korrekten Code. Da muss man nicht aus einer optimierten "Set-Abfrage" die komplett in den CPU Registern abläuft, einen Funtionsaufruf und Bit-Operationen auf RAM durchführen. Wenn ich bei Embarcadero arbeiten würde, wäre CharInSet sicherlich meine erste Wahl, da dort "langsam und schlecht" seit ein paar Jahren vorherrscht.

[Bernhard Geyer]

Zitat:

Zitat von jbg (Beitrag 1289918)

Und was macht ein JSON Parser der UTF8 "on the fly" bekommt? Einfach mal zwischen einer multi-byte UTF8-Sequence in UTF16 konvertieren dürfte interessante Ergebnisse liefern. Am Ende spuckt er schon einen UTF16-"Baum" aus, aber zum Parsen nutzt er UTF8.

Die JSON-Schnittstelle ist für mich Außenschnittstelle. Und dieser liefert ja mittlerweile Emba. Und sobald ich die Wert einlese habe ich ja normale Unicodestrings.

Zitat:

Zitat von jbg (Beitrag 1289918)

Zitat:

Ich denke dafür kann man auch eine überladene Version von CharInSet definieren um sowas zu verstecken

Pfui. CharInSet ist für einen Parser der letzte Unsinn. Der Compiler generiert für CharSets mit nur ASCII-Zeichen den korrekten Code. Da muss man nicht aus einer optimierten "Set-Abfrage" die komplett in den CPU Registern abläuft, einen Funtionsaufruf und Bit-Operationen auf RAM durchführen. Wenn ich bei Embarcadero arbeiten würde, wäre CharInSet sicherlich meine erste Wahl, da dort "langsam und schlecht" seit ein paar Jahren vorherrscht.

Den Quellcode habe ich mir hier noch nicht angesehen um das zu beurteilen. Da ich aber keine Zeitkritische Operation mit viele CharInSet-Abfragen habe ist mir hier auch nix aufgefallen.