Quo vadis Delphi XE8 ?

[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 von 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.

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 von Bernhard Geyer:

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 von jbg:

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 von jbg:

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.

[jbg]

Zitat von Bernhard Geyer:

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.

Hätte Emba da mal lieber eingekauft, statt das selbst zu fabrizieren. Die Performance, vor allem unter Android, ist unterirdisch. Wofür andere Implementierungen unter 5 Sekunden brauchen, da verbrät die Embt-Variante 30 Sekunden (mein Nexus 5) und verschlingt auch noch unmengen an RAM: 3 GB für eine 180 MB große JSON Datei (Benchmark)