wchar_t érdekesség

Itt olvasható: https://stackoverflow.com/questions/76283563/how-can-i-compile-and-gene…

TL;DR Az AIX gyári headerjei nem C++-kompatibilisek, legalábbis ami a wchar_t-t illeti (C++-ban beépített típus, nem szabad typedef-elni. Köszönjük, Emese Bjarne!)

( apal v | 2023. 05. 20., szo – 12:36 )

Hm... mar eleve ez a `short wchar_t` is egy erdekes allatfaj lehet... I (and/or anything relevant codespaces nowadays) 👍 it! 

Mondjuk nem elsőre nyilvánvaló, hogy mit panaszol a C++ fordító. Neki ez olyasmi, mintha 'typedef short char' lenne, vagyis egyrészt hibás a 'short char', másrészt nincs megadva a definiálandó típus neve.

Ja és ami egyszer 16 bites volt volt, az annyi is marad (Windows, Aix32) a kompatibilitás miatt. Ebből az is kiderül, hogy a kérdező az SO-n még 32-biten próbálkozik, mert Aix64-ben a wchar_t már 32-bites.

( uid_6201 v | 2023. 05. 22., h – 15:25 )

Hát a wchar_t egy érdekes történelmi állatfaj. Ez 16 bites lett elsőre, feleslegesnek tűnt a 4 byte elcseszése.

Több programozási nyelvnél okozott fejfájást, amikor a unicode 16 bit fölé hízott. De hát kell bele a piros alma 🍎 sőt a zöld alma 🍏 karakter is.

Jaja, az kb pont annyira minosegi ganyolas es tkp dobhatod ki az egesz wchar_t koncepciot akkor, mert strlen() != wchar_t darabszam. Szoval ugyanott vagy, komplexitasban, mintha kb UTF8-as strlen()-t implementalnal, ellenben kozehuztal meg egy reteget teljesen feleslegesen. Akkor meg minek szopni az egesz short alapu wchar-os kretenseggel? 

Mivel az strlen() bemeneti típusa const char* és nem const wchar_t*, ezért nem is lenne használható, helyette van megfelelője, a wcslen().

Miért gondoltad, hogy az strlen()-nek működnie kéne más típusú bemeneti adatra? Ilyen erővel működnie kéne const uint8_t*-ra is. Viszont megsúgom, sehol nincs leírva, hogy a char típusnak pontosan 8 bitesnek kell lennie . CHAR_BIT hosszúnak kell lennie, a gépi legkisebb címezhető egység méretének, de legalább 8 bitnek.

Miért gondoltad, hogy az strlen()-nek működnie kéne más típusú bemeneti adatra? 

Persze, ebben tokeletesen igazad van. De nem is erre gondoltam gondolt a kolto pontosan. Hanem ugye mi is volt lett a gyakorlatban:

  • 8 bitet (vagy CHAR_BIT-et, mindegy) meghalado code pointok megjelentek - nyilvan, mert sok nyelv, nyelvekben sok betu, ez kell.
  • stlren() jellegu fuggvenyek, (es barataik, uzletfeleik) nem fognak mukodni, mert nem tudjuk faek egyszeru megszamolni: encoding szimbolumok szama != code pointok szama
  • oke, bevezetjuk a wchar_t, hogy megszamolhassuk egyszeruen, hogy a fenti egyenloseg igaz legyen
  • ja, azzal sem tudjuk mert a/ tulleptuk a code pointok szamaval b/ kicsi a tipus c/ mindketto 
  • de sebaj, biztos jo ez igy, mert mar ket adattipus is letezik ami ezt nem tudja az elemi "szamoljuk meg" muveletet, pl egy tombre vagy barmilyen linearis adatstrukturara! 

Szoval nekem inkabb ez a fenntartasom ezzel az egesz wchar_t-vel. Es akkor a topiknyito kollega ennek valamifele aspektusaba belefut, merthat milyen jo is ez. Biztos egy bizottsag tervezte.

Csak simán régebbi, mint az unikód, szóval a szabvány csak annyit mond róla, hogy 'hát a wchar_t, az bizony valami, vagy legalábbis lesz valami'
Ettől függetlenül az utf8 (vagy utf32) sem annyira egyszerű, mint hinnénk, pl. ez itt milyen hosszú (és milyen mértékegységben mérve): ю́ (cyrillic small letter yu with acute)? (forrás: http://utf8everywhere.org/)

Pontosan 1 karakter, 2 code point és kódolástól függő számú byte. Lehet, hogy a jövőben majd 1 code point lesz belőle, ki tudja. Nehéz dolog az emberi írást modellezni az informatika eszközeivel. Mint ahogy nehéz a lakcímeket is modellezni, a dátumokat és naptárrendszereket, a neveket, és nagyon sok minden más emberi dolgot. Az emberek nem rigid struktúrákban működő lények, a gépek meg igen, a kettő között kell valahogy áthidalást alkotnunk.

A wcslen miért ne működne? Megszámolja, hogy hány karakterből áll a megadott wchart_t*. 

Az meg miért is probléma, hogy a kódolt byte-ok száma nem egyezik meg a karakterek számával? A karakter totál más absztrakció, mint a byte.

A wcslen() megmondja a karakterek számát, az strelen() meg a byte-ok számát, amennyiben wchart_t*-t adsz neki paraméterül. Melyik elemi "számoljuk meg" műveletet nem tudja a standard library? Mindkét absztrakció megszámolására van benne művelet.

Az meg miért is probléma, hogy a kódolt byte-ok száma nem egyezik meg a karakterek számával? 

Hogy a byteok szama nem egyezik meg az nyilvan nem baj, de hogy csinalsz egy szarmaztatott tipust, nyilvan azert hogy egyszerusitse az eletet (indexelhetoseg, linearis darabszam, barmi), es meg az sem tudja ezt akkor minek...? Beleteszem akkor egy void*-ba vagy `typedef whatever* string`-be a karakterlancot, oszt megszamoltatom, annyi. 

Ha azt mondanank hogy a wchar_t egy olyan tipus ami "minden, codepage altal tamogatott karakter bele kell ferjen", akkor vagy tul sok lesz a felfeher terhes ferfi a karaktersorzatban es jon az unexpected exception, vagy sima linearis cimzest csinalsz es jo vagy. De ez a "surrogate pair" az annyira egy ganyolt taknyolas (vagy taknyolt ganyolas) ebbe az egeszbe, hogy mar akkor igen hamar felmerul a kerdes bennem hogy "oke, szep meg jo, de minek?".

De lehet hogy csak en foglalkozom tul sok ilyesmivel kritikusabb mukodtetesu beagyazott rendszeres barmikben, oszt emiatt magasak az elvarasok :] 

Senki nem mondta neked, hogy a wchar_t nem lenne jó erre, ugyanis lehet akár 64 bit széles is, és simán elfér benne minden Unicode code point. 

"Ha azt mondanank hogy a wchar_t egy olyan tipus ami "minden, codepage altal tamogatott karakter bele kell ferjen""

Ez így aluldefiniált. Milyen codepage? A programonként egyedileg használt input/output kódolási formátum miért lenne hatással egy programnyelv típusdefiníciójára?
A surrogate pair pont azért van, mert túl sokan építettek arra, hogy a wchar_t az mindig 16 bit, hogy kellett erre egy workaround. Mint ahogy a Java char is 16 bites csak, meg a Pascal WideChar is. Illetve azért építettek erre, mert az Unicode 1.0 ezt definiálta - nem volt eléggé absztrakt még. Az egész surrogate pair az amiatt van, hogy az Unicode 2.0+ visszafelé kompatibilis legyen az Unicode 1.0-val.

Mondhatnánk, hogy a wchar_t egy olyan absztrakció legyen, amibe belefér 1 Unicode code point, nem specifikálva a hogyant (a bitmintára való kódolást - mivel abból sok van).
Lineárisan mit akarsz címezni? Karaktereket? Byte-okat?