Biblioteki łatające dziury standardu C++

Co dokładnie dałoby przyjęcie używania zawsze UTF-16, lub UTF-32? Tzn poza całkowicie zbędnymi konwersjami?

Na przykład kontrolę nad tym, w czym masz zakodowany tekst, czy format danych zapisanych do pliku. Żeby stworzyć przenośny program używający , który zapisywałby plik na jednym systemie a na drugim odczytywał, trzeba by było się trochę nagłowić. Warto by też było wiedzieć, czy możesz użyć algorytmu, który wymaga RandomAccessIteratorów, bo na jednym systemie może być dozwolony a na drugim już nie.

Za to Ty zjadłeś wszystkie umysły :)

Szczerze, to nie wiem o co Ci chodzi. Moja wypowiedź była trochę tendencyjna, ale poparta argumentami. Jeśli nie mam racji to znaczy, że podałem złe argumenty i chyba lepiej jest mnie poprawić niż tak pisać.

Wyciągnij n-ty znak z tekstu Utf8 ze zlozonoscia O(1) - powodzenia :)

Nie rozumiem jaki to ma związek z tym co pisałem. W mojej wypowiedzi chodziło o to:

• UTF-8 ma tą zaletę, że zajmuje mało miejsca w pamięci, więc jest przydatny do przechowywania przetworzonego tekstu

• UTF-32 zajmuje więcej miejsca w pamięci ale za to możliwe jest stworzenie RandomAccessIteratora, dzięki czemu o wiele lepiej nadaje się do wykonywania operacji na nim

Za to nie jestem w stanie dostrzec żadnych zalet w UTF-16, który ani nie jest najbardziej oszczędny pamięciowo ani nie jest możliwe stworzenie RandomAccessIteratora.
Should UTF-16 be considered harmful?
Oni też wydają się zgadzać ze mną.
Skoro  raz jest kodowany w UTF-16 a raz w UTF-32 to według mnie jest mało przydatny.

Bardzo podobna sytuacja jest z typem . Zgadnijcie dlaczego wolę używać  oraz  osobno, z pełną świadomością co robię?

Dlaczego od razu bezużyteczny? Jak masz znaki mieszczące się co najwyżej na dwóch bajtach, to wybór tego kodowania jest dość rozsądnym pomysłem.

Przesadziłem trochę z bezużytecznością. Są przypadki, że UTF-16 staje się rozsądnym wyborem, ale wciąż jest ich mało. Połączenie UTF-32 dla przetwarzania i UTF-8 do przechowywania wydaje się być najbardziej racjonalne.

Zgodność wsteczna. UTF-8 jeszcze wtedy nie istniało, a cały Unikod mieścił się na dwóch bajtach.

To całkowicie zmienia postać rzeczy. Nie wiedziałem tego.

Żeby stworzyć przenośny program używający std::wstring , który zapisywałby plik na jednym systemie a na drugim odczytywał, trzeba by było się trochę nagłowić.

Przenośność nie zawsze idzie w parze z szybkością działania. Jeśli ważniejsza jest przenośność, to nic nie stoi na przeszkodzie, aby dołożyć dodatkowe warstwy pośrednie (nawet jeśli przez to program będzie działał nieco wolniej). Natomiast jeśli w danym przypadku liczy się szybkość działania, to lepiej dopasować się do konkretnego środowiska. Skoro Windows wymaga UTF-16, to takie dane należy mu dostarczyć (co nie zmienia faktu, że sam kod źródłowy możesz trzymać w UTF-8, a napisy mieć w oddzielnym pliku i przy budowaniu exeka wykonywać odpowiednie konwersje, jeśli zachodzi taka potrzeba).

Skoro Windows wymaga UTF-16, to takie dane należy mu dostarczyć

Zgadzam się, ale mam pewne zastrzeżenie. Mówisz o szybkości działania. Ona może się znacznie różnić, kiedy wykonujemy operacje na . Dla UTF-32 algorytm będzie wydajniejszy a UTF-16 wolniejszy. Czy więc nie lepiej jest na każdym systemie używać UTF-32 a tylko w momencie korzystania z API tłumaczyć to na odpowiedni format?

Na przykład kontrolę nad tym, w czym masz zakodowany tekst, czy format danych zapisanych do pliku.

To co innego. W formacie pliku zawsze jest jasno zdefiniowane kodowanie tekstu i trzeba ewentualną konwersję wykonać. Czy trzeba wszędzie w programie używać takiego samego kodowania? Nie.

Warto by też było wiedzieć, czy możesz użyć algorytmu, który wymaga RandomAccessIteratorów, bo na jednym systemie może być dozwolony a na drugim już nie.

Wszędzie można, pytanie tylko czego potem od tego oczekujesz. Jeśli znaki są z BMP, to masz przełożenie 1-1 punktów unicode na wartości UTF-16. Jeśli chcesz wspierać języki używające znaków spoza BMP, to samo wsparcie Unicode nie wystarczy. Będziesz mógł powiedzieć "wspieramy wasze znaki, ale to co robimy z tekstem nie ma sensu".

Jezeli nie widzisz problemu w odczytaniu n-tego znaku ze zlozonoscia O(1) z utf8 to znaczy, że nie rozumiesz tego kodowania i nigdy nie zaimplementowales zadnego algorytmu operujacego na tekscie utf8.

/edit:
Tak by the way:

only use Win32 functions that accept widechars (LPWSTR). Never those which accept LPTSTR or LPSTR. Pass parameters this way: ::SetWindowTextW(Utils::convert(someStdString or "string litteral").c_str())

W tym przypadku zamiast napisać po prostu:
propozycją autora tego posta jest zrobienie:

Naprawdę... zacny kod :)

/edit:
Dodam jeszcze: wynalazki są tak bardzo użyteczne jak bardzo się one integrują z istniejącymi rozwiązanymi. Możesz powiedzieć "wstring jest ble", a potem zrób aplikację, która odczyta Ci z dysku plik posiadający w nazwie polskie znaki (pod Windowsem). Bang! Leżysz :) A jak to nawet jakoś przebrniesz to podbijemy stawkę do chińskich znaków :) wówczas okaże się, czy zrobiłeś workaround czy poprawnie polityczną obsługę kodowania.

Wymyślacie jakieś sztuczne problemy. Nie można po prostu użyć ICU (http://site.icu-project.org/)?

Wyciągnij n-ty znak z tekstu Utf8 ze zlozonoscia O(1) - powodzenia :)

Z UTF-16 tak samo się nie da. Nawet z UTF-32 się nie da, bo pojedynczy znak może się składać z wielu code pointów. Jakby ktoś tego faktycznie bardzo potrzebował, to da się w O(logn), ale mam lepsze pytanie: do czego miałoby wyciągnięcie n-tego znaku służyć?

Jezeli nie widzisz problemu w odczytaniu n-tego znaku ze zlozonoscia O(1) z utf8 to znaczy, że nie rozumiesz tego kodowania i nigdy nie zaimplementowales zadnego algorytmu operujacego na tekscie utf8.

Zakładam, że to do mnie. Pierwszy raz naprawdę Cie nie rozumiem DejaVu. Nigdzie nie pisałem o odczycie n-tego znaku ze złożonością O(1). Z całym szacunkiem ale upierasz się na to, ale nie ma to nic wspólnego z tym, o czym rozmawiamy.

propozycją autora tego posta jest zrobienie: C/C++ ::SetWindowTextW( Utils::convert( MalaLiteraLzOgonkiemWUtf8 + MalaLiteraAzOgonkiemWUtf8 + "ka" ).c_str() )

Przecież tu chodzi o coś całkowicie innego. Jemu chodzi o to, że jeśli chcesz przekazać LPSTR () lub LPTSTR (), to lepiej będzie samodzielnie to przekonwertować na .

Możesz powiedzieć "wstring jest ble", a potem zrób aplikację, która odczyta Ci z dysku plik posiadający w nazwie polskie znaki (pod Windowsem). Bang! Leżysz :)

Ani konstruktor  ani też metoda  nie przyjmują a. Wnioskuję, może błędnie, że akceptują one UTF-8, a UTF-16 już nie.

Edit:
Ten temat powinien się chyba nazywać

std::wstring and UTF-16 is [CENSORED]. Change my mind.