Jan Patera wrote:Salamander bohuzel nepouziva makra LPTSTR, ktera by prechod ulehcila.
Překlopit současné deklarace "char" na "TCHAR" je banalita. V případě Salamandera to bohužel nebude zdaleka vše, viz toto vlákno.
V nedávné době Petr upravil memory management. Alokace již nevrátí při nedostatku paměti NULL, ale místo toho proces zobrazí okno s tlačítkem Retry. To by nám mohlo znatelně odlehčit kód (chybové stavy v případě nedostatku paměti).
Druhou věc z tohoto soudku zvažujeme v případě řetězců právě při přechodu na Unicode. Při zpracování cest přejít ze statických bufferů na nějaké inteligentní alokované, protože ty statické už nás několikrát vypekly. Zároveň je tu možnost zapouzdřit takový buffer do objektu a zprůhlednit současné konstrukce, které stále dokola hledají lomítko na konci cesty a je jich plný Salamander. Počítače jsou řádově rychlejší, tak bychom si za přehlednější a stabilnější kód nějaký overhead asi mohli dovolit. Uvidíme, na co najdeme odvahu.
Jan Patera wrote:zarevak wrote:Jan Patera wrote:"Dulezitost" rozsirencyh CJK znaku a fakt, ze bez nich "nelze zit", IMHO ilustruje i fakt, ze byly pridany az do Unicode 3.1 v breznu 2001.
Nevím, proč si spojujete UNICODE jen s CJK. .
Nespojuji. Altap sveho casu (stale?) tvrdil, ze musi podporovat UTF-16, protoze UCS-2 nestaci, protoze CJK.
Přiznávám, že jsem se ztratil. Ptáš se jestli si myslíme, že pro Salamandera (operace nad FS) nebude stačit podpořit Unicode na úrovni UCS-2 a že by Salamander měl umět
minimálně to co umí Windows Explorer na jednotlivých platformách? Tak to si stále myslíme.
Zjednodušeně řečeno: nebude stačit vynásobit velikosti bufferů x2 a přepsat "char" na "TCHAR", protože nově se s cestama bude pracovat jako s variable-length encoding řetězcema.