Vlákno názorů k článku Interní reprezentace řetězců v různých jazycích: od počítačového pravěku po současnost od kvr - Hezké shrnutí. Ještě dneska si pamatuju na to...

Asiatům je to jedno, bo v naprosté většině případů vidí dva byty jak v UCS-2, tak UTF-8 :-) A pořád je tam dost věcí (HTML, JavaScript, JSON, kódy v localization), které budou z velké části ASCII, takže i tak ušetří.

K druhé části - spíš mít dva různé typy pro různé účely. I to málo situací, kde se používá .charAt(), povětšinou stačí implementace po bytech, bo se třeba jen porovnávají dva řetězce, bere se substring, ale na nějaký kód apod (typicky nějaký parser, který při nalezení speciálního znaku (což je obvykle ASCII) vezme předchozí sekvenci bytů a vyrobí z něj String). Těch situací, kdy je skutečně vyžadován random access k char (codepoint) dle indexu, je jako šafránu. Takový UcsString by se případně mohl cachovat v rámci původního Utf8 String, i když pochybuju, že by to mělo dramatický přínos (s výjimkou GUI aplikací, ale tam ty řetězce obvykle nebývají enormně dlouhé).

A jo, jsem si vždycky myslel, že je to o dost víc. To autoři v rámci blbuvzdornosti UTF-8 ten prostor docela promrhali :-)

Díky za opravu!

Máš pravdu, ten příklad je pro x86, už jsem to opravil.

Mimochodem ty příklady s hello world mám připravené pro víc architektur, takže v případě zájmu sosejte na https://github.com/tisnik/presentations/tree/master/assembler/03_gas_hello_world (pro PPC a s390 to vytvorili guruove na tu platformu, ja bych to nedal :-)

"Myšlenka v python 3.3 je zajímavá, ale když budu generovat nebo číst nějaké XML a ukládat do string bufferu, tak kvůli pozdravu českého uživatele bude celá anglická stránka čtyřikrát (či dvakrát) větší"

Bude to dvakrát větší (viz ten příklad s "ěščř...." na konci článku), ale například pro různé webservicy, kde se přenáší mraky datových XML nebo JSONy to je fajn, tam je to většinou čisté ASCII. Dtto SVG a podobné XML implementace.

Pokud ty data obsahují třeba jména nebo adresy (což obvykle obsahují), tak to bude plýtvat. Pokud půjde jenom o nějaké měření, souřadnice apod., tak ano - tam to bude ASCII.

Na druhé straně je pravda, že chytré implementace budou nejspíš serializovat rovnou do nějakého UTF-8 byte stream, nikoliv char stream či string. Viz třeba Jackson, který má parsery pro byte array, byte stream, char stream atd. (a kde ty první dva jsou dvakrát rychlejší než poslední zmíněný :-) ).

To je pravda, určitě to na vstupu/výstupu takto bude. Ale když si představíš, jak například nějaká aplikace zpracuje vstupní JSON, který dostane z web servicy:

vstup -> obrovský řetězec (tady se může plýtvat, záleží na knihovně) -> parsing -> (teď se klidně na původní řetězec může pustit GC) -> slovník (slovníků/polí)

A u toho slovníku ty "chytré řetězce" dost pomůžou, protože můžeme dostat něco takového:


{ "firstName" : "Méďa",
"surname": "Béďa",
"comment": "pije ",
"validated": True,
"ID": 42}


Takže samozřejmě hodnoty budou muset být v UCS-2 nebo u nějakých paznaků co tam uživatel dá v UCS-4 (kupodivu to má nízký kód), ale minimálně u klíčů to bude Latin-1 (předpokládáme příčetného programátora :-)

PS: čistě teoreticky ten původní string nepůjde na GC, pokud nějaká knihovna "optimalizuje" substring() tak, že se vrací jen reference někam doprostřed původního pole.

Ok předchozí příspěvek měl za "pije " znak http://www.fileformat.info/info/unicode/char/2615/index.htm dtto v poznámce (kupodivu to http://www.fileformat.info/info/unicode/char/2615/index.htm má nízký kód). Omlouvám se, redakční systém asi nepoužívá Unicode :-)