Devadesátková hra Brány Skeldalu prošla portací a je dostupná na platformě Steam. Vyšel i parádní blog autora o portaci na moderní systémy a platformy včetně Linuxu.
Lidi dělají divné věci. Například spouští Linux v Excelu. Využít je emulátor RISC-V mini-rv32ima sestavený jako knihovna DLL, která je volaná z makra VBA (Visual Basic for Applications).
Revolut nabídne neomezený mobilní tarif za 12,50 eur (312 Kč). Aktuálně startuje ve Velké Británii a Německu.
Společnost Amazon miliardáře Jeffa Bezose vypustila na oběžnou dráhu první várku družic svého projektu Kuiper, který má z vesmíru poskytovat vysokorychlostní internetové připojení po celém světě a snažit se konkurovat nyní dominantnímu Starlinku nejbohatšího muže planety Elona Muska.
Poslední aktualizací začal model GPT-4o uživatelům příliš podlézat. OpenAI jej tak vrátila k předchozí verzi.
Google Chrome 136 byl prohlášen za stabilní. Nejnovější stabilní verze 136.0.7103.59 přináší řadu novinek z hlediska uživatelů i vývojářů. Podrobný přehled v poznámkách k vydání. Opraveno bylo 8 bezpečnostních chyb. Vylepšeny byly také nástroje pro vývojáře.
Homebrew (Wikipedie), správce balíčků pro macOS a od verze 2.0.0 také pro Linux, byl vydán ve verzi 4.5.0. Na stránce Homebrew Formulae lze procházet seznamem balíčků. K dispozici jsou také různé statistiky.
Byl vydán Mozilla Firefox 138.0. Přehled novinek v poznámkách k vydání a poznámkách k vydání pro vývojáře. Řešeny jsou rovněž bezpečnostní chyby. Nový Firefox 138 je již k dispozici také na Flathubu a Snapcraftu.
Šestnáctý ročník ne-konference jOpenSpace se koná 3. – 5. října 2025 v Hotelu Antoň v Telči. Pro účast je potřeba vyplnit registrační formulář. Ne-konference neznamená, že se organizátorům nechce připravovat program, ale naopak dává prostor všem pozvaným, aby si program sami složili z toho nejzajímavějšího, čím se v poslední době zabývají nebo co je oslovilo. Obsah, který vytvářejí všichni účastníci, se skládá z desetiminutových
… více »
10.1.2012 11:08
alblaho | skóre: 17
| blog: alblog
AbcLinuxu.cz
ITBiz.cz
HDmag.cz
AbcPráce.czsizeof(),...).
Jinak ale práce s polem je opravdu jen pointerová aritmetika.
Tenhle kus kódu by to mohl snad objasnit, je to alternativní zápis přístupu k prvku pole:
#include <iostream>
using namespace std;
int main()
{
int a[3] = {1, 2, 3};
cout << 2[a] << endl;
return 0;
}
Záleží na tom, co si představíš pod pojmem pole; v mém případě je to ten soubor hodnot; v tvém případě je to de facto syntaktický prvek jazyka C (resp. interface k pointerový aritmetice na vyšší úrovni). O tom tvém alternativním zápisu vím, ale nepoužívám jej.
ref funguje podobně, ale nedojde ke změně hodnoty venku, pokud se explicitně nezmění vevnitřA za tým je potom:
reference jsou většinou implementované pomocí pointerů, ale jako pointery se nechovají, protože není možné změnit hodnotu, na kterou ukazujíčo sa celkom vylučuje.
No, je to myšleno tak, že posílání po referenci je v podstatě posílání aliasu; pokud se nezmění hodnota argumentu uvnitř funkce, tak se venku nic neděje; pokud ano, tak se projeví změna i venku.
Tudíž zápis:
void foo(ref int bah) { bah = 10; }; int x = 5; foo(x);
vyústí v to, že x bude pak 10, ale kdyby foo bylo
void foo(ref int bah) {}
tak se nic neděje, hodnota zůstává 5. Tak to není v případě "out" atributu, který by v prvním případě fungoval stejně, ale v druhém případě by po zavolání foo bylo x 0. Zápis:
void foo(ref int bah) { bah = 10; }; int x = 5; foo(x);
je ekvivalentní s
void foo(int* bah) { *bah = 10; }; int x = 5; foo(&x);
Reference jsou proto implementovány většinou pomocí pointerů, ale sémanticky se chovají jako aliasy.
reference jsou většinou implementované pomocí pointerů, ale jako pointery se nechovají, protože není možné změnit hodnotu, na kterou ukazujímyslim ze touhle vetou chtel rict ze neni mozne zmenit referenci tak aby ukazovala na novou adresu. Ale je pravda ze ta veta to nerika
Cčkaři vědí, že hodnoty různých typů se automaticky neinicializují a je třeba explicitně specifikovat hodnotu. Toto neplatí v případě D. Všechny integrální typy jsou implicitně 0.To je z poloviny pravda. Hodnoty nejsou inicializované, jedná-li se o lokální proměnou, čili proměnnou alokovanou na zásobníku, kdy hodnota je náhodná (viz vývojáři Debianu a generování certifikátů). Jde-li o globální, či statickou proměnnou, je inicializována na binární 0 (není-li hráno s přepínači překladače, apod.). Martin
Typ char je jedna UTF-8 jednotkaNie je mi to jasné. Vôbec mi to nie je jasné.
11.1.2012 01:36
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
11.1.2012 01:45
pavlix | skóre: 54
| blog: pavlix
Jde o to, že znaky s diakritikou, jenž mají vyšší kód znaku než 127 (nikoliv 255, protože 1b se používá k signalizaci UTF-8 znaků s větší hodnotou, ten 1b říká že následující znak je součástí aktuálního) jsou zapsány jako vícero znaků typu char.Snažíš se zmást nepřítele termilologií z ASCII? V popisu UTF-8 nemůžeš používat slovo znak jako synonymum bajtu, když jeho základní vlastností je, že znak nemá vždy stejný počet bajtů.
11.1.2012 01:47
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Pokud použiješ UTF-16 (wchar), jedna jednotka představuje 16b, takže se ti do jedné jednotky vejde jeden český znak.Český znak sice jo (vlastně jakejkoli ne-obskurní
), ale jinak obecně utf-16 není fixed-width...
11.1.2012 02:30
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
11.1.2012 09:19
pavlix | skóre: 54
| blog: pavlix
12.1.2012 23:39
pavlix | skóre: 54
| blog: pavlix
Utf-16 představuje dost dobrý paměťově-výkonový optimum při práci s řetězci.To jistě, hlavně při práci s východoasijskými jazyky. Ale ty výkonově-paměťové nároky podle mě nepřeváží rizika chyb včetně bezpečnostních, které UTF-16 může při špatném otestování na proměnnou délku představovat. A přecijen riziko neobjevení chyb daných proměnnou délkou znaku je u UTF-8 podstatně menší než u UTF-16, srovnej kolik uživatelů se nevejde do ASCII a kolik se nevejde do BMP.
Ale ty výkonově-paměťové nároky podle mě nepřeváží rizika chyb včetně bezpečnostních, které UTF-16 může při špatném otestování na proměnnou délku představovat.Jako vsechny bezpecnostni rizika pri praci s polem, toto neni argument.
A přecijen riziko neobjevení chyb daných proměnnou délkou znaku je u UTF-8 podstatně menší než u UTF-16, srovnej kolik uživatelů se nevejde do ASCII a kolik se nevejde do BMP.Od toho jsou unit testy, popripade jina forma testovani.
14.1.2012 08:24
pavlix | skóre: 54
| blog: pavlix
Jako vsechny bezpecnostni rizika pri praci s polem, toto neni argument.Díky za upozornění, že to není argument.
Od toho jsou unit testy, popripade jina forma testovani.Bylo na tom, co jsem napsal, něco nesrozumitelného? Mimochodem, doporučuju někdy konfrontovat teorii s praxí.
Na druhou stranu je UTF-16 z hlediska pameti nejlepsi volbatady nekdo po ranu jedl ftipnou kasi...
12.1.2012 23:34
pavlix | skóre: 54
| blog: pavlix
Na druhou stranu je UTF-16 z hlediska pameti nejlepsi volbaKecy nemaj cenu. Zkus si to tvrzení aspoň obhájit. Zjevně podle tebe platí obecně, tak to zkus třeba s češtinou, to je taková zlatá střední cesta. Nicméně, doporučím ti k přečtení ten příspěvek, u kterého jsi omylem klikl na odkaz „odpověďět“.
Q: How should I handle supplementary characters in my code? A: Compared with BMP characters, the supplementary characters are relatively uncommon in most contexts. That fact can be taken into account when optimizing implementations for best performance: execution speed, memory usage, and storage. This is particularly useful for UTF-16 implementations, and to a lesser degree in UTF-8 implementations.Utf-16 ti umožňuje rychlý stringy - v 99% procentech případů má přístup ke znakům složitost O(1), což výrazně zjednodušuje i další stringové operace. Zároveň oproti utf-32 zabírá pouze (téměř, v 99%) polovičku paměti. Takže pro práci s řetězci je to imho dost optimální. (Jinak ale na serializaci jsem osobně pro utf-8).
Ono ani nevim o runtime, kde by se UTF-32 vyuzivalo.Dart. Teda, tam jsou Stringy v paměti vždycky s fixní velikostí znaku, a to buď jednobajtovou, nebo dvoubajtovou, nebo čtyřbajtovou.
14.1.2012 20:54
pavlix | skóre: 54
| blog: pavlix
Utf-16 ti umožňuje rychlý stringy - v 99% procentech případů má přístup ke znakům složitost O(1), což výrazně zjednodušuje i další stringové operace.Což je právě až příliš dobrý výsledek, viz výše.
14.1.2012 22:17
pavlix | skóre: 54
| blog: pavlix
14.1.2012 22:43
pavlix | skóre: 54
| blog: pavlix
14.1.2012 23:31
pavlix | skóre: 54
| blog: pavlix
14.1.2012 23:54
pavlix | skóre: 54
| blog: pavlix
sorry ze to tak musim rict, ale tohle je fakt blabol. Proste mas kodovani s promenou delkou a tak s nim tak musis pracovat. A ne se to snazit zamest pod koberec, tvrdit uzivateli tridy ze operace maji slozitost O(1), pak tam nekdo zada "nespravny" retezec a cely se to sesype...Ale né, ve chvíli, kdy někdo zadá "nesprávný řetězec", tak se akorát změní ten flag, použijí se příslušné algoritmy a nic se nesesype...
dalsi vec je ze dost podcenujes overhead spojeny s udrzbou toho flagu. sice se tim nezmeni asymptoticka slozitost ale to neznamena ze se to nezpomali...Tak jasný, ten flag nějakou režii mít bude, pořád je to ale ještě imho o řád lepší než pracovat se všemi stringy jako by obsahovaly surrogate pairs...
for (i = 0; i < s.len(); ++i)
{
... s[i] ...
}
a to ok v zadnym pripade neni, muzes si to prat sebevic...
a pri nespravnym retezci se to sice technicky vzato nesesype, jenom se nedockas vysledku.
operator[]() se přece postará o správné procházení stringem právě na základě toho flagu, od toho ten flag je. To vlastní pole, ve kterém jsou uložena syrová data, je zapouzdřeno.
(To se tady opravdu snažim sdělit tak složitou myšlenku, nebo co se děje?)
ok to neni protoze pri nespravnym retezci to ma kvadratickou slozitost misto linearni.Cože?!? Proč?
pritom je tady jednoduchy reseni - nepredstirat ze je to kodovani s pevnou delkou, kdyz neni, a pouzit iterator.Nic nepředstírám, plně počítám s tím, že to kódování s proměnnou délkou je, a pro (vhodně implementované) iterátory jsem všema deseti.
Cože?!? Proč?On asi myslel to, kdybys ten operator[] volal pro kazdy znak v poli (pouzil to jako iterator).
15.1.2012 15:15
pavlix | skóre: 54
| blog: pavlix
Přijde mi, že se nám tu snaží pánové pavlix a extremni lama dokázat, že když se utf-16 stringy špatně použijí, vzniknou potíže. Což je tedy skutečně objev...Jsem rád, že jsi to alespoň po takové době objevil. Teď ještě vypilovat porozumění textu, protože já jsem bohužel od začátku předpokládal, že toto ti bude jasné. Co se týče uživatele __dart__, tak tomu jsem vyvracel cca tři nesmyslná tvrzení: 1) Že UTF-16 má (obecně) nejmenší paměťovou náročnost z trojice UTF-8, UTF-16 a UTF-32, což je celkem triviální matematika. 2) Že se na Unicode.org tvrdí (1), nacož je myslím dostatečné to, že se to vůbec netvrdí v citaci, kterou on nakonec použil. Co se týče toho sdělení tobě. Už nevěřím, že bys to vůbec mohl či dokonce chtěl pochopit... ale ještě jednou, a jednodušeji: Implementace UTF-16 bude IMO obsahovat podstatě více extrémně málo používaného kódu než implementace UTF-8. A ten extrémně málo používaný kód se týká zpracování textových řetězců proměnné délky a výpočtu délky řetězcové proměnné v paměti. Případné chyby vedou na zranitelnosti v buffer overflow. Když bude do kódu zasahovat lama, která si v roce 2012 myslí, že v Unicode mají znaky 16 bitů neboli dva bajty (a že takových je!), tak je velká pravděpodobnost, že lama vytvoří bezpečnostní díru. U UTF-8 toto neplatí. Pokud u UTF-8 lama přecijen použije předpokladu, že počet kódových jednotek je stejný jako počet znaků, tak si toho možná angličtí kolegové bez zájmu o typografii nevšimnou. Ale všimnou si toho češtní, fracouzští, španělští, němečtí a jiní. A ty, jsi navrhl, že by se používaly dva různé algoritmy, jeden pro BMP řetězce a jeden pro řetězce s aspoň jedním ne-BMP znakem. A navíc jsi tvrdil, že tím je problém vyřešený, což je tak zřejmý nesmysl, že kdybys měl koule, tak bys to dávno uznal. Tím množství rizikového kódu zvyšuješ a pravděpodobnost objevení chyby, která se v něm nachází, snižuješ. Q.E.D.
15.1.2012 15:19
pavlix | skóre: 54
| blog: pavlix
vyvracel cca tři nesmyslná tvrzení:3) Že mu vyvracím nesmyslné tvrzení č. 1, protože jsem si na něj zasedl :).
Implementace UTF-16 bude IMO obsahovat podstatě více extrémně málo používaného kódu než implementace UTF-8. A ten extrémně málo používaný kód se týká zpracování textových řetězců proměnné délky a výpočtu délky řetězcové proměnné v paměti.S extrémně málo používaným kódem se setkáš v bezpečnosti na každém kroku. O tom v podstatě velká část bezpečnosti ošetření vstupu je. Viz např.
Když bude do kódu zasahovat lama, která si v roce 2012 myslí, že v Unicode mají znaky 16 bitů neboli dva bajty (a že takových je!), tak je velká pravděpodobnost, že lama vytvoří bezpečnostní díru. U UTF-8 toto neplatí.Pokud bude do kódu zasahovat lama, napáchá pravděpodobně řadu dalších problémů než jen zpracování textu. Pokud bude do kódu zasahovat lama, nedá se na bezpečnost toho kódu spolehnout. A to platí ať už použiješ utf-8, utf-16, utf-32, utf-over9000 anebo i když vůbec nebudeš zpracovávat text. Takže toto opravdu není argument.
A ty, jsi navrhl, že by se používaly dva různé algoritmy, jeden pro BMP řetězce a jeden pro řetězce s aspoň jedním ne-BMP znakem. A navíc jsi tvrdil, že tím je problém vyřešený, což je tak zřejmý nesmysl, že kdybys měl koule, tak bys to dávno uznal.Ale prd, tys akorát absolutně nepochopil, jak jsem to myslel. Místo toho tady mlátíš ostatní koulema...
15.1.2012 15:38
pavlix | skóre: 54
| blog: pavlix
Pokud bude do kódu zasahovat lama, napáchá pravděpodobně řadu dalších problémů než jen zpracování textu. Pokud bude do kódu zasahovat lama, nedá se na bezpečnost toho kódu spolehnout. A to platí ať už použiješ utf-8, utf-16, utf-32, utf-over9000 anebo i když vůbec nebudeš zpracovávat text. Takže toto opravdu není argument.Pokud rozdíl v náročnosti revize celého kódu i jednotlivých patchů, případně napsání smysluplných testů, a daších věcí nevidíš, tak to pak naprosto chápu tvé „ach jo“. Ona je jedna věc, když je to implementace unicode pro python, javu nebo jiné vysokoúrovňové jazyky, a jiná věc, pokud je to třeba pro céčko a programátor má přímý přístup ke všemu. V tom druhém případě jsi v prdeli asi podobně, jako jsi byl v prdeli s Pythonem 2 a automatickými konverzemi, s tím rozdílem, že ty vždycky vedly „jenom“ na vyhození výjimky a v případě neošetření „jenom“ na pád serveru.
Ale prd, tys akorát absolutně nepochopil, jak jsem to myslel.A čí je to chyba? Moje nebo tvoje?
Místo toho tady mlátíš ostatní koulema...Ty jsi schizofrenik, že pro sebe používáš množné číslo a slova jako „ostatní“? Nebo to má být plural majestaticus nebo jak se tomu říká?
Pokud rozdíl v náročnosti revize celého kódu i jednotlivých patchů, případně napsání smysluplných testů, a daších věcí nevidíš, tak to pak naprosto chápu tvé „ach jo“.Nějak se mi nedaří z týhle věty vydestilovat smysl. Rozdíl mezi čím a čím?
Ona je jedna věc, když je to implementace unicode pro python, javu nebo jiné vysokoúrovňové jazyky, a jiná věc, pokud je to třeba pro céčko a programátor má přímý přístup ke všemu.Tak, a teď se zeptej sám sebe: Týká se tento problém s nízkoúrovňovostí céčka pouze UTF-16, nebo se týká prakticky čehokoli v céčku? Já musím prostě souhlasit s kolegou Darkem v tom, že jsi zřejmě proti UTF-16 zaujatý, protože mi přijde, že sveřepě hledáš problémy, které s podstatou UTF-16 ani moc nesouvisí - jako například to, že programátor je lama nebo to, že v C je problematické zapouzdření. Tyto problémy jsou v zásadě off-topic.
A čí je to chyba? Moje nebo tvoje?Nejspíš na obou stranách...
Ja vlastne ani moc nechapu, o tady resi. Nejdulezitejsi knihovny/prostredi pouzivaji UTF-16 (vcetne API ruznych mobilnich zarizeni) a pavlix ani extremni lama s tim nic neudelaji. To, co tady predvadi je demagogie a zamerne nepochopeni prispevku. Ja uz teda nemam silu, ani vuli :)
UTF-16 je zkratka zlaty stred - pametove nejefektivnejsi:) nejvykonnejsi:) nejodolnejsi vuci chybam:) Nejbezpecnejsi (neplati pro pavlixe:)) A jako bonus, nepouzivaji ho silenci:)
15.1.2012 19:17
pavlix | skóre: 54
| blog: pavlix
15.1.2012 19:55
pavlix | skóre: 54
| blog: pavlix
pritom je tady jednoduchy reseni - nepredstirat ze je to kodovani s pevnou delkou, kdyz neni, a pouzit iterator. Sice tim programatora trochu omezis a u nekterych veci se bude muset trochu vic zamyslet, ale vysledek bude rychlejsi a bude mit predvidatelnou slozitost. Jenomze ve chvili kdy si prizname ze UTF-16 je kodovani s promennou delkou tak si taky musime priznat ze proti utf-8 a utf-32 ma jenom nevyhody... a to si tady nekdo nechce priznat ze...Tomuhle člověku říkáš troll? To je fakt jak házet perly sviním, takové pěkné vysvětlení. Už to nehul.
Co se týče druhého odstavce, tak bohužel ty "nevýhody utf-16" tady zatím ani jeden z vás moc nerozvedl - viz níže.UTF-8: + kompatibilni s ASCII + nizka spotreba pameti + nejsou problemy s little/big endian + nejsou potreba zadny konverze pro IO, v podstate staci zkopirovat blok pameti na vystup (souvisi s kompatibilitou s ascii) - variable length UTF-32: - nekompatibilni s ASCII - vysoka spotreba pameti - nevhodny pro IO (problemy s little/big endian, programy pracujici s ascii budou UTF-32 retezec povazovat za binarni data) + fixed length celkove UTF-32 muze byt za urcitych okolnosti vhodny pro interni reprezentaci a pro urcity algoritmy UTF-16: - nekompatibilni s ASCII - vysoka spotreba pameti - nevhodny pro IO (problemy s little/big endian, programy pracujici s ascii budou UTF-16 retezec povazovat za binarni data) - variable length jedina castecna vyhoda utf-16 je ze nektery knihovny to z historickych duvodu jeste stale pouzivaji...
16.1.2012 10:00
pavlix | skóre: 54
| blog: pavlix
Ok, dejme tomu, ale úplně férové to není, u UTF-8 jsi vůbec nevzpomněl na negativum hodně složitého algoritmu v porovnání s ostatními dvěma (ano, i v porovnání se zpracováním surrogate pairs v UTF-16).Od toho tu jsi ty, abys to doplnil, ne? Jak jsem říkal, nehledej hned špatný úmysl. Ale když jsem ho implementoval, tak vůbec složitý nebyl, aspoň při použitá shl a and to bylo úplně na pohodu. Ale ve srovnání s UTF-16 či bych ti to uznal. Ve srovnání s UTF-32 to je přímo obsaženo v tom, že UTF-32 je fixed.
No a UTF-8, pokud máš smůlu, zabere víc než UTF-16.Tak ta smůla dost závisí na volbě jazyka.
Že je UTF-16 nevhodný pro I/O, to určitě souhlasim, osobně bych také serializoval do UTF-8.Pokud serializuju do UTF-8, tak potřebuju vážný důvod, abych v paměti měl něco jiného :).
15.1.2012 20:40
pavlix | skóre: 54
| blog: pavlix
Jestli jste ty nebo lama měli dojem, že se snažim tvářit, že je utf-16 fixed-wdithMy ten dojem ještě máme, že se pro 99% procent případů chceš chovat k UTF-16 jak fixed width, a na ten zbytek dělat special case. Mimochodem, doporučuju ti se podívat na dohady o special casing konverze mezi čísly a jejich textovou reprezentací v různých soustavách v Pythonu. Tam je to čistě kvůli optimalizaci a už teď jsou ohlasy, že je tam special cases tolik, že pokrývají celou škálu reálného užití té funkce (jsou tam special cases pro mocniny dvou a pro desítku :D). Jen zajímavost.
Co se týče druhého odstavce, tak bohužel ty "nevýhody utf-16" tady zatím ani jeden z vás moc nerozvedlOk, tedy nevýhody nasazení UTF-16 oproti UTF-8 1).Nevýhodou je paměťová náročnost, to lama pokud vím psal. U češtiny možná o 70%, nepočítám, jen odhaduju. 2) Nevýhodou je naprostá nekompatibilita s ASCII. Kde UTF-8 funguje samo od sebe, UTF-16 se musí doimplementovat. Příkladem budiž programovací jazyky. ASCII znaky fungují, non-ASCII znaky se při kompilaci vůbec nemusí řešit. Navíc to tak už funguje díky dlouhé tradici osmibitových kódování kompatibilních s ASCII. 3) Nevýhodou je problém s endianess při serializaci. 3a) Tím pádem nemůžeš identický formát používat v souboru i v paměti, což způsobuje, že musíš konvertovat data při čtení i zápisu. 3b) Tím pádem potřebuješ udržovat informaci o kódování souboru, například ve značce na začátku souboru, čímž ztratíš funkcionalitu klasických shellovských příkazů včetně třeba
cat!
3b) Ztratíš všeobecně uznávaný předpoklad, že nulový bajt ukončuje řetězec, což asi není tak zásadní, ale je to nepříjemnost.
4) Mnou zmíněný special casing, který ty jako nevýhodu neuznáváš.
Nicméně děláš chybu, protože v případě nízkoúrovňových jazyků
se to dotýká bohužel i kódu aplikací.
5) Takovou menší nevýhodou je že si programátoři UTF-16 pletou se starším šestáctibitovým Unicode, a při použití aplikace v běžných jazycích si toho nikdo nemá šanci všimnout. Ale jde to proti smyslu Unicode.
Jsem si jistý, že by se těch nevýhod našlo i víc, ale mě osobně 2 a 3 přijdou kritické, 4 zásadní, 5 nepříjemná, a 1 zbytečná, když není vyvážena dostatečnou výhodou.
Kvůli kterékoli z 2, 3 a 4 bych u nového projektu volil UTF-8. U staršího projektu bych měnil kódování jedině při nějakém velkém rewritu, jinak bych upgradoval starý unicode na UTF-16 a zakázal vývojářům zpracovávat UTF jinak než jednou sadou otestovaných rutin
a snažil se vymyslet další způsoby, jak jim zabránit v tom to zkurvit.
Když se podíváš normálníma očima, zjistíš, že se __dark__ projevuje jako troll a když ho s tím pošleš do háje ty, akorát tím stoupneš. Já na tebe nebudu používat argumenty typu „my jsme dva, tak víme líp“, tak špatně na tom ještě nejsem :).
Extremni lama se jako troll nechová a má u mě oběd za trpělivost, pokud se někde potkáme třeba na konferenci.
Když se podíváš normálníma očima, zjistíš, že se __dark__ projevuje jako troll"Normální oči" bych chtěl vidět, ty budou asi vedle prototypu metru v Paříži (sarkastický smajlík). Jinak mně Darkovy komentáře nepřijdou o nic víc trolující než tvoje Lorem Ipsum nebo lamův kód s operátorem
[], který byl zcela mimo mísu - uznávám, že to ale bylo možná jen nedorozumění.
15.1.2012 22:05
pavlix | skóre: 54
| blog: pavlix
Ad 1. Ano, utf-16 je náčročnější na paměť, považuju to za výměnu za rychlost.Zase vágní kecy. Ve spoustě věcí je UTF-8 rychlejší :).
Ad 2. a 3. Souhlasím, pro serializaci preferuju utf-8. Konverze utf-8/utf-16 při čtení/zápisu mi nepřipadá jako problém...Před chvíli jsi psal něco o tom, že dáváš přednost rychlosti :).
4. Proč vnímáš special casing jako takovou nevýhodu? A tím myslim konkrétně u utf-16, ne obecně...Special casing je nevýhoda obecně kvůli náchylnosti na chyby. Konkrétně u UTF-16 jsem to několikrát popsal, ale že seš to ty... protože v tomhle případě je to special casing pro velikost přidělené paměti a zavání to stack overflow a podobnými.
Jinak mně Darkovy komentáře nepřijdou o nic víc trolujícíTo je mi líto.
Lorem IpsumLipsum jsem ti napsal jen jednou a měl bys uznat, že to bylo na příspěvek, ve kterém nešlo najít souvislost s příspěvkem, kde jsi kliknul na tlačítko odpovědět. Ale dejme tomu, že to bylo na hraně :). Zase mě omlouvá to, že aspoň vím, o čem píšu.
lamův kód s operátorem [], který byl zcela mimo mísu - uznávám, že to ale bylo možná jen nedorozumění.Pokud nevíš, máš předpokládat dobrý úmysl, ne špatný. V tomhle případě neshledávám jediný náznak špatného úmyslu. IMO má k trollování dál než ty, který opakovaně tvrdíš, že jsi neviděl žádný argument, když jsi ho opakovaně dostal :). Sáhni si taky do vlastního svědomí. Dokonce mi ani jeho příklad nepřipadá jako blbost, prostě chtěl jenom nějakou ukázku, na které to půjde porovnat. Její relevanci jste ani moc nediskutovali.
Zase vágní kecy. Ve spoustě věcí je UTF-8 rychlejší :).A tohle vůbec není vágní tvrzení, že...
Před chvíli jsi psal něco o tom, že dáváš přednost rychlosti :).Při serializaci je imho typicky úzké hrdlo jinde.
Special casing je nevýhoda obecně kvůli náchylnosti na chyby. Konkrétně u UTF-16 jsem to několikrát popsal, ale že seš to ty... protože v tomhle případě je to special casing pro velikost přidělené paměti a zavání to stack overflow a podobnými.Sorry, ale ani teď ani předtím jsi to nepopsal dostatečně konkrétně. Že to někomu něčím "zavání" to je možné, ale jestli to má mít váhu, budeš opravdu muset být konkrétnější. V jakém případě by tam mohl nastat ten overflow? (Ad trolling: myslim, že nemá smysl se přetahovat o to, kdo víc troluje...)
16.1.2012 10:10
pavlix | skóre: 54
| blog: pavlix
A tohle vůbec není vágní tvrzení, že...Je :). Ale nejsou to takové kecy, jako že přechodem na UTF-8 získáš rychlost. To by totiž byl úplně stejný kec jako že ji získáš přechodem na UTF-16. Něco je rychlejší a něco je pomalejší, nehledě na to, že pochybuju, že by to bylo nějak významné (v obou případech).
Sorry, ale ani teď ani předtím jsi to nepopsal dostatečně konkrétně. Že to někomu něčím "zavání" to je možné, ale jestli to má mít váhu, budeš opravdu muset být konkrétnější. V jakém případě by tam mohl nastat ten overflow?Kolikrát ti to mám ještě napsat? Overflow hrozí ve chvíli, kdy se zamění počet kódových jednotek s počtem znaků. Když se budeš snažit, najdeš to minimálně v pěti komentářích, spíš více. Nepřipadáš si trochu natvrdlý? Mě teda v téhle diskuzi docela jo. Budu pomalu končit, už se mi zobrazují příspěvky po slovech, což naznačuje, že jsem se pustil do jirsákovské diskuze a to mi přijde jako ztráta času.
Kolikrát ti to mám ještě napsat? Overflow hrozí ve chvíli, kdy se zamění počet kódových jednotek s počtem znaků.Ale vždyť ten special casing nic takového nedělá... Pouze interně volí různé algoritmy pro výpočet počtu znaků pro různé stringy, to je všechno... Ne, asi máš recht, tohle opravdu ztrácí smysl...
15.1.2012 19:16
pavlix | skóre: 54
| blog: pavlix
Nejdulezitejsi knihovny/prostredi pouzivaji UTF-16 (vcetne API ruznych mobilnich zarizeni) a pavlix ani extremni lama s tim nic neudelaji.Nemůžu mluvit za lamu, kterýžto vůbec lamou není, ale mě nijak nevadí, že knihovny, které jsou pro tebe nejdůležitější, používalí z historických důvodů původní šestnáctibitový Unicode, a možná některé znich už stihli cestou nejmenšího odporu upgradovat na UTF-16, ale dost možná z nich většina o UTF-16 ještě ani nezavadila. Nejdůležitější knihovni s jejichž kódem jsem se setkal, používají UTF-8, a ani __dark__, který tak rád převádí IT oblast na emocionální úroveň, aby nedej bože nemusel používat kritické myšlení, natož přiznat, že napsal totální blbost, která by platila jen pokud by 1.2 bylo větší než 2.0.
UTF-16 je zkratka zlaty stred - pametove nejefektivnejsi:) nejvykonnejsi:) nejodolnejsi vuci chybam:) Nejbezpecnejsi (neplati pro pavlixe:))Prostě něco jako Windows (co si tak pamatuju instalační obrazovky).
A jako bonus, nepouzivaji ho silenci:)Chápu, že ti připadám jako šílenec, když si umím spočítat relativní četnosti a takové věci. Holt „vyšší level“ (z mého pohledu ale základy).
Tobě asi nedošlo, že tuhle četnost jsme si tu spočítali úplně všichni, jenom ty máš potřebu z ní vyvozovat podivné závěry. Shrňme si tvoje argumenty proti UTF-16:
15.1.2012 21:05
pavlix | skóre: 54
| blog: pavlix
Používají to Windows (emocionální argument)Moc se ti omlouvám, za to, že jsem ti výše ptal slušně a chápavě. Takže pokud teď nenajdeš citaci, kde tvrdím, že UTF-16 je špatné, protože to používají Windows, budu tě považovat za blbce.
Když to použije lama, je dost možné, že to zkazíTo není argument, ale platný předpoklad pro argument, který záměrně vynecháváš, protože sis zřejmě už vnitřně uvědomil, že mám pravdu. Jinak bys rozporoval můj skutečný argument.
V jazyce C jsou s tím podobné problémy jako se vším ostatnímTo slova tvá jsou.
(Zapomněl jsem na něco?)Napsal jsi tři argumenty, které jsi mi lživě přisoudil pro to, abys mě následně mohl shodit. Jenže, tady nejsi před šéfem, kde potřebuješ sbírat laciné body za to, že někoho neprávem shodíš. Tady shazuješ jen sebe a to nejen odborně, ale i charakterově.
Kromě toho, opravdu by mě zajímalo, jak by to dopadlo, kdyby lama implementovala UTF-8. Imho by to nebylo lepší, možná spíš ještě horší, ono UTF-8 taky není úplně triviální dobře implementovat a má svoje záludnosti.Na UTF-8 se IMO dřív umlátí vlastníma testama na nějakém Evropském jazyce. Na UTF-16 ne. Ale to je detail, spíš než problém v UTF knihovně bych viděl problémy v aplikaci, kde v 99% půjde použít oběcně mylný předpokad, že počet kódových jednotek je stejný jako počet znaků. U dynamických jazyků mě zajímá prakticky jenom API, takže vnitřní UTF-16 implementace mi přijde sice zbytečná, ale pokud se to neprojevuje navenek ani na bezpečnostních chybách, je mi to upřímně jedno.
16.1.2012 15:46
Bystroushaak | skóre: 36
| blog: Bystroushaakův blog
| Praha
Místo toho tady mlátíš ostatní koulema...Tak to bych fakt chtěl vidět v praxi. Je to jedna z těch věcí, u které mi vůbec nedochází jak by se měly prakticky implementovat. Možná kdyby si uřízl péro a jednu nohu, nebo nevim :) PS: Teď mě napadá že by mohl mít nějaké ufiklé na provázku/klacku a mlátit s nimi ostatní, což by mohlo být docela efektivní.
15.1.2012 01:12
pavlix | skóre: 54
| blog: pavlix
Jenomze ve chvili kdy si prizname ze UTF-16 je kodovani s promennou delkou tak si taky musime priznat ze proti utf-8 a utf-32 ma jenom nevyhody... a to si tady nekdo nechce priznat ze...Myslím, že teď jsi na to kápnul :).
14.1.2012 11:01
pavlix | skóre: 54
| blog: pavlix
Mam pocit, ze tve reakce se spis zameruji na mou osobu, nez na dane tema.Nemám ponětí kdo jsi, ani co jsi, takže neshledávám žádný důvod zaměřovat své reakce osobně. Zato tvé obvinění z mé zaujatosti mi osobní připadá, takže se můžeš představit a sdělit mi, co jsem ti udělal zlého :). Teda teď už o tobě vím, že neumíš počítat, což lze přímo odvodit od toho, že považuješ UTF-8 za obecně efektivnější než UTF-16. Ale takových, co neumějí počítat znám mnoho, takže ani to ti nezajišťuje jedinečnost.
O prednosti UTF-16 je zminka i na unicode.org, ale to jsou asi jenom kecy.Argumentum ad verecundiam. Tím zde neoslníš. Vzhledem k tomu, že jsi necitoval konkrétní znění, a vzhledem k tomu, že mi ještě nedorazila křišťálová koule, kterou jsem si objednal, můžu jenom tipovat. A osobně tipuju, že zrovna toto na unicode.org mají napsáno správně, pouze že jsi to špatně pochopil.
Nemám ponětí kdo jsi, ani co jsi, takže neshledávám žádný důvod zaměřovat své reakce osobně. Zato tvé obvinění z mé zaujatosti mi osobní připadá, takže se můžeš představit a sdělit mi, co jsem ti udělal zlého :).Tak si asi zaujaty jen vuci UTF-16
Teda teď už o tobě vím, že neumíš počítat, což lze přímo odvodit od toho, že považuješ UTF-8 za obecně efektivnější než UTF-16. Ale takových, co neumějí počítat znám mnoho, takže ani to ti nezajišťuje jedinečnost.Nechapu, proc sem pises takove vylevy a jeste mi podsouvas neco, co jsem nikde nenapsal.
Argumentum ad verecundiam. Tím zde neoslníš....
Vzhledem k tomu, že jsi necitoval konkrétní znění, a vzhledem k tomu, že mi ještě nedorazila křišťálová koule, kterou jsem si objednal, můžu jenom tipovat. A osobně tipuju, že zrovna toto na unicode.org mají napsáno správně, pouze že jsi to špatně pochopil.Stacilo napsat, ze chces link, treba v poznamkach UTF-16: http://unicode.org/notes/tn12/ . Mi osobne z hlediska zpracovani textu prijdou nejzajimavejsi tento:
UTF-8 was mainly designed to store Unicode filenames in an ASCII-friendly way. It is suitable for processing, but it is significantly more complex to process than UTF-16. Lead bytes have a relatively complex encoding, and up to three trail bytes (or five to cope with the original definition) must be counted, read and range-checked, then the resulting code point must be range-checked as well.a
UTF-16: From a programming point of view it reduces the need for error handling that there are no invalid 16-bit words in 16-bit Unicode strings. By contrast, there are code unit values that are invalid in 8/32-bit Unicode strings. All pairs of lead/trail surrogates in UTF-16 represent valid supplementary code points, and reading 16-bit Unicode requires to look ahead at most one unit.Conclusion:
Unicode is the best way to process and store text. While there are several forms of Unicode that are suitable for processing, it is best to use the same form everywhere in a system, and to use UTF-16 in particular for two reasons:At si to kazdy prebere jak chce.
The vast majority of characters (by frequency of use) are on the BMP.
For seamless integration with the majority of existing software with good Unicode support.
15.1.2012 09:00
pavlix | skóre: 54
| blog: pavlix
Tak si asi zaujaty jen vuci UTF-16Kolik takových uhozených teorií máš ještě v zásobě?
Nechapu, proc sem pises takove vylevy a jeste mi podsouvas neco, co jsem nikde nenapsal.Zapomněl jsem tam napsat „z hlediska paměti“, jinak viz tvé:
Na druhou stranu je UTF-16 z hlediska pameti nejlepsi volbaNebo to psal někdo jiný pod tvoji přezdívkou?
At si to kazdy prebere jak chce.Díky za prostor k interpretaci. Vidím to tak, že můj tip byl naprosto správný. Že je UTF-16 z hlediska paměti nejlepší, se tam nepíše ani zdaleka. Naopak se tam píše o důvodu z hlediska kompatibility s původním, jinak definovaným, Unicode, což se týká právě serializace. Řetězce v programovacích jazycích můžou používat abstrakci, která interní reprezentaci vůbec neexponuje (pole znaků například tak jak se používá v Pythonu 3).
Tiskni
Sdílej:
