Re: Delphi 2009/2010 ohne Unicode?

Hubert Seidel schrieb:

Meine Kurzfassung:
EVA = Eingabe/Verarbeitung/Ausgabe

Wenn Eingabe und Ausgabe ANSI ist,
dann möchte ich in Bauch nicht mit Unicode
arbeiten da zum einen die Eingangskonvertierung
und die Ausgangskonvertierung überflüssig ist,
zum anderen die Verarbeitung im "Bauch"
toppelt so viele Bytes transferieren muss.

Das sehe ich genauso.

Ich gehe mal davon aus, das die 256 darstellbaren
Zeichen in UTF-16 keine Surrogate-Pairs benötigen.

Allgemein: Zeichen aus der Unicode BMP.


Einmal nach UTF-16 konvertiert kann der UnicodeString ohne
weitere Konvertierung der Windows API übergeben werden und
in der GUI angezeigt werden, wenn das kein Vorteil ist?

Wenn ich jedoch bei Ansi bleiben kann, und weiterhin
zur Stringmanipulation Ansi-Funktionen zur Verfügung habe,
dann habe ich halb so viel Speicherdurchsatz.

In Cobol wird zwischen Usage=Display und Usage=Computational unterschieden. Vielleicht sollte man das in Delphi genauso sehen, bei der Festlegung des jeweils passenden Stringtyps.

Und nur weil ein W-API-Aufruf präzise mit allen
möglichen Zeichen umgehen kann, geht es nicht besser,
wenn eh nur die 256 möglichen aus ANSI 1252 enthalten sind.

Bei ASCII war ToUpper und ToLower eine reine Funktion, die ein Bit im Zeichen entsprechend gesetzt hat.

Bei Ansi (SBCS) ist für jede Codepage eine eigene Tabelle notwendig, mindestens für den non-ASCII Teil. Bei MBCS mehrere Tabellen, mit entsprechend mehrstufigem Lookup.

Bei Unicode (UTF-32) wird nur eine Tabelle benötigt, die aber durch die vielen Löcher ebenfalls baumartig mit mehrstufigem Lookup aufgebaut sein dürfte.

Bei UTF-16 für UCS4 werden solche Funktionen und die übergebenen Parameter noch aufwendiger, da auch bei einzelnen Zeichen immer mit Strings (Surrogat-Paare aus mehreren WideChars) zu rechnen ist.

Damit dürfte klar sein, daß eine Beschränkung auf einen bestimmten Zeichensatz deutliche Optimierungsmöglichkeiten bietet. Dann kommt es drauf an, ob diese Optimierungsmöglichkeiten in der RTL wahrgenommen werden, z.B. in Abhängigkeit vom String-Typ oder -Encoding.

Ein Anwendungsprogrammierer muß bei der Verwendung von Unicode schon genau angeben (und sicherstellen), warum z.B. seine indizierten Zugriffe auf String-Elemente überhaupt zulässig sind. Bei Ansi war das einfach, da eine Codepage entweder SBCS oder MBCS ist. Bei Unicode kann man sich zwar entsprechend auf die BMP beschränken, es gibt dann aber keine Sperren, welche die Einhaltung dieser Annahme sicherstellen.


Es bedeutet unterm Strich _weniger_ Konvertierungen!

Wenn ich ein Ansi-String mit einer Ansi-Funktion
aufrufe könnte, warum sollte konvertieren wollen?

Was die Benennung der Delphi-Funktionen betrifft, da hat sich CodeGear dazu entschlossen, die alten Namen aus Kompatibilitätsgründen beizubehalten, aber die Ansi Parameter durch Unicode zu ersetzen. Wenn man das weiß, kann man bei Ansi-Texten um diese Funktionen einen weiten Bogen machen. Benutzerfreundlicher wäre jedenfalls eine eigene (überladene) Implementierung für AnsiString Parameter.


Wenn du einen AnsiString in einer Ansi-Anwendung anzeigst
oder nur einmal AnsiUpperCase aufrufst hat Windows den String
schon intern hin und her konvertiert!

Ich hab's selber nicht nachgeprüft, aber wenn ein WinAPI ToUpperA nach ToUpperW delegiert, dann ist das eine herbe Bremse. (s.o.)

DoDi
.

Relevant Pages

  • Re: ASCII 8Bit unter DBCS
    ... 255 Zeichen) Informationen. ... VBunter DBCS verweigert die Kenntnis ... Codierung Unicode oder auch mit Stream auf UTF-8 lesen und schreiben. ... ich das Textfile in ANSI. ...
    (microsoft.public.de.access)
  • Re: Delphi 2009/2010 ohne Unicode?
    ... zur Stringmanipulation Ansi-Funktionen zur Verfügung habe, ... Zeichen entsprechend gesetzt hat. ... Ich denke, _wenn_ man unbedingt Unicode benötigt, ... Nur grob 2x mehr Durchsatz/Langsamer gegenüber Ansi, ...
    (de.comp.lang.delphi.misc)
  • Re: Call C DLL from VB.net-problem..array gains 4 bytes!
    ... No, Unicode strings don't, by definition, have a header with the size. ... you're writing code in C++, for example, the only difference between an ANSI ... which take an array of bytes. ... > Remember the DLL declaration... ...
    (microsoft.public.windowsce.app.development)
  • Re: Why use other encoding then UTF-8 when this support almost every language
    ... But for most of them the Unicode standard ... Eventually this OEM free-for-all got codified in the ANSI standard. ... characters, noncharacter, etc. ...
    (microsoft.public.dotnet.languages.csharp)
  • Re: DrawText / DT_CALCRECT
    ... If it's ANSI, I'd try a Unicode build, and if that's not feasible, you ... I'm afraid I can't switch to Unicode. ... Now, the REAL solution is to first compute the size, THEN do an allocation of the buffer ... incorrect!); you are not allocating far more, or far fewer, bytes of buffer than you need; ...
    (microsoft.public.vc.mfc)