| A co toupper zwraca dla '4'? |
Bardziej chodziło mi o to, że można trafić na implementacje, które ustawiają jakieś flagi błędów lub rzucają wyjątki, gdy czegoś nie uda się zrobić. Oczywiście w przypadku
toupper najlepiej byłoby zwracać taki sam znak, ale nie zawsze jest to możliwe. Jeśli chodzi o standardową wersję tej funkcji, to za jednym razem można zwrócić pojedynczy bajt, więc należałoby wywołać taką funkcję kilka razy (oddzielnie dla każdego bajtu) i jednocześnie zadbać o to, aby kolejne wyniki pośrednie dały łącznie odpowiedni znak w danym kodowaniu, przy określonych ustawieniach lokalnych i jeszcze aby to było bezpieczne wielowątkowo. Zrobienie czegoś takiego prawidłowo może być niewykonalne lub wymagać rzucania wyjątków, więc czasami lepiej po prostu użyć czegoś innego lub solidnie obłożyć to testami (albo po prostu nie wywoływać takich funkcji na problematycznych znakach nakładając ograniczenia na dane wejściowe).
| Wsparcie standardu dla unicode: |
Drobna uwaga techniczna: do wypunktowania można używać znaczników
[pkt][/pkt] zamiast myślników.
| zwracają liczbę elementów w tablicy a nie ilość znaków |
Jak już wspomniałem, to zależy od tego, co chcesz zrobić. Zapisując coś do pliku potrzebujesz ilości bajtów, a nie znaków Unikodowych.
| metody find, find_first_of itd nie mają pojęcia, że niektóre znaki mogą być zakodowane na więcej niż 1 code pointcie, więc praktycznie rzecz biorąc - nie działają poprawnie |
Jeśli znak jest poprawnie zakodowany w UTF-8, to nie da się zapisać tego samego znaku na dwa sposoby. Używaj metod działających na napisach wszędzie, gdzie korzystasz z Unikodowych znaków (i tak musisz mieć jakąś zmienną o rozmiarze większym niż jeden bajt, aby zrobić to prawidłowo). Z jednobajtowych wersji korzystaj wewnętrznie do trywialnych działań lub nie używaj ich wcale.
| nie ma std::u16cout ani std::u32cout, mimo że jest, zależny od platformy, std::wcout. To samo z std::cin. |
| nie ma std::u16fstream ani std::u32fstream |
| nie ma żadnego identyfikatora dla std::stringa, że przechowuje UTF-8 a nie ASCII |
Do czego potrzebujesz czegoś takiego? Jeśli
char *
albo
wchar_t *
zawiera odpowiednie bajty, to całość będzie właściwie wyświetlona. Podaj przykład, w którym to nie działa zgodnie z oczekiwaniami i nie wynika na przykład z błędnie ustawionego kodowania znaków w Twoim IDE.
| Przed C++17, z tego co wiem, korzystając z <fstream> nie było możliwości otworzenia plików o ścieżce zakodowanej inaczej niż w ASCII. |
To już zależy od implementacji, ja jakoś nie miałem z tym większych problemów. A skoro teraz masz do dyspozycji nowości z C++17, to z nich korzystaj, o ile jest to możliwe. Zresztą, w najprostszych przypadkach wystarczy ograniczyć się do jednobajtowych znaków, a w tych bardziej skomplikowanych i tak pewnie zajdzie potrzeba jakiejś obsługi systemu plików, możliwość zarządzania folderami, obsługa skrótów (czy tam symlinków), więc i tak zaczniesz szukać do tego oddzielnej biblioteki, która zapewne będzie udostępniała coś lepszego niż narzędzia z
#include <fstream>
.
| nie istnieją utfXiteratory, które pozwalałyby sprawnie iterować po kolejnych znakach. Trzeba pisać to samemu |
Albo szukać biblioteki, która umie robić takie rzeczy. Chociaż, jeśli korzystasz z UTF-8, to ten format jest na tyle regularny, że policzenie liczby znaków Unicode (w takim znaczeniu, w jakim wynik jest równy liczbie znaków zapisanych w UTF-32) nie powinno stanowić większego problemu. A jeśli chcesz na przykład traktować znak i akcent jako jeden znak, to i tak trzeba zagłębić się w złożoność Unikodu, więc przyda się do tego oddzielna biblioteka. Chociaż i tak jeśli chcesz to zrobić na jakimś skończonym podzbiorze Unikodu, to te tablice znaków są na tyle regularnie rozłożone, że pewnie da się to jakoś prosto zapisać.
O tym już chyba wspominałem. Nie ruszaj ich, jeśli jest to możliwe.
Dlatego moim zdaniem najrozsądniejszym podejściem jest ograniczenie się do jakiegoś prostego, działającego kodu i stopniowe rozszerzanie tego w miarę potrzeb. Osobiście przy pisaniu własnych programów zwykle dochodziłem do wniosku, że wystarczy wspierać jakiś niewielki podzbiór Unikodu, a resztę dodawać wtedy, gdy okaże się to konieczne.
| jeśli miałbyś napisać sprawnie działający edytor tekstu, to jakich bibliotek byś użył? |
SFML, RapidXML, trochę biblioteki standardowej i parę własnych narzędzi. Chociaż niewykluczone, że może coś z SFGUI albo wxWidgets by się przydało... Ewentualnie jakiś podzbiór WinAPI, gdyby to miało być tylko pod Windowsa i koniecznie musiało być napisane w C++. SFML spokojnie poradzi sobie z czcionkami, RapidXML może się przydać do serializacji oraz do wspierania plików XML, SFGUI albo wxWidgets załatwi potrzebne kontrolki, a WinAPI obejmuje Windowsa i zawiera z grubsza to, co potrzeba, aby się do niego dopasować.
| czy wyciągnąłbyś tylko jego kawałek i umieszczał na repozytorium razem z nim czy raczej korzystał z całości i do repo trafiłaby tylko informacja "dołącz boosta w wersji takiej i takiej" |
Linkowałbym statycznie tam, gdzie się da i dynamicznie tam, gdzie muszę (bo na przykład licencja tego wymaga). Przy okazji trzeba byłoby jeszcze sprawdzić, czy licencje wszystkich bibliotek się ze sobą nie gryzą i jakoś to rozsądnie poustawiać.