Takie może dziwne pytanie ale dlaczego Qt nie używa std::string ?
0
2
Bo Qt jest starsze niż std::string i nie chciało im się migrować?
6
Bo pochodzi z epoki C++ łupanego, przez co musiało wynajdywać wiele rzeczy samemu, bo albo ich jeszcze nie było w standardzie, albo były nieużywalne do ich potrzeb.
2
no i dodatkowo było by sie cofnięcie w rozwoju np. qstring ma metodę split.
8
- bo Qt zaczęło się dawno temu w 1990, gdy stan standardowej biblioteki był jeszcze gorszy, nie było jeszcze STL-a - ergo nie było std::string.
-
std::wstringjest platform depended. Znaki mają 16 (windows) lub 32 bitów (inne systemy) - bo
std::wstringnie ma jasnego oznaczania kodowania - bo wsparcie
std::localeprzez kompilatory było i jest słabe - bo potrzebowali czegoś jednolitego na wszystkie platformy
- bo chcieli mięc thread safety i Copy On Write (COW) a przed C++11 nie było gwarancji na thread safety dla std::basic_string
- bo API dla
std::basic_stringjest ubogie i dziwne. - ....
3
ale dlaczego Qt nie używa std::string ?
Zakładając, że std::string istniałby w czasie kiedy powstawał Qt to i tak nie zostałby użyty bo ogranicza on lokalizację. QString wspiera utf16 czyli może zakodować pełnego unicode więc zakładając, że przewidziałeś dla programu możliwość tłumaczeń na różne języki, masz możliwość przetłumaczyć go na cokolwiek.
QString jest narzędziem, które Qt jako framework gui potrzebuje, dopasowane pod ich potrzeby by zapewnić klientom biblioteki odpowiednie ficzery. Kontenery z STL, w tym std::string to uogólnione rozwiązania, które nie zawsze będą najlepszym wyborem do każdego zastosowania.
2
MarekR22 napisał(a):
std::wstringjest platform depended. Znaki mają 16 (windows) lub 32 bitów (inne systemy)
To jest tragedia. UTF-16 jest natywnym, wewnętrznym kodowaniem Windowsa (i nie jest nim UTF-8 bo UTF-8 jeszcze nie istniało gdy Windows przechodził na Unicode!). wchar_t i wstring używają zatem kodowania które nie wymaga żadnej konwersji przy wołaniu systemowych API.
32-bitowy wchar_t i wstring na unixach nie ma sensu, jest marnotrawstwem miejsca i jest prawie bezużyteczny.
2
.. 8 ... bo komitet standaryzacyjny C++ ma "specyficzny" kontakt z realnym życiem
0
ZrobieDobrze napisał(a):
.. 8 ... bo komitet standaryzacyjny C++ ma "specyficzny" kontakt z realnym życiem
ale to chyba Qt powinno iść w kierunku standardów ? — Adamek Adam 5 minut temu
W normalnie zarządzanych językach tak jest.
W C++ firma / fundacja / zespół która jeszcze nie zrobiła swojego stringa, zaraz go zrobi, bo nie będą mięczakami. Polska dla Polaków, ziemia dla ziemniaków, a std:string dla ... (banują za takie słowa)
To samo kontenery.
4
ale to chyba Qt powinno iść w kierunku standardów ?
Którego standardu? Biblioteki standardowej czy standardu unicode? Bo ani char and wchar_t nie są bezpośrednio związane z unicode. Dopiero niedawno zostało dodane wsparcie dla UTF8, ale moim zdaniem jego wsparcie to żart i wciąż to nie jest pełen UNICODE.
Jeśli potrzebujesz wsparcia dla UNICODE w swoim systemie C++ i chcesz zachować higienę umysłową to używasz do tego third party i tutaj nie jako standardem jest użycie ICU https://unicode-org.github.io/icu/userguide/icu/howtouseicu.html, którego Qt używał pod spodem, przynajmniej w wersji piątej, w szóstej nie wiem jak jest.
(edit)
W C++ firma / fundacja / zespół która jeszcze nie zrobiła swojego stringa, zaraz go zrobi, bo nie będą mięczakami
Własny string w C++ to taki programistyczny mem chyba. To chyba pokłosie tego, że własny string to było jedno z ulubionych ćwiczeń zadawanych na uczelniach i o zgrozo, jeśli odejmiejmy COW to co bardziej rozgarnięty student był w stanie stworzyć implementacje nie dużo gorszą od tego co było w standardzie. Tym nie mniej teraz gdy mamy SSO, std::string_view do pary i narzędzia z pmr nie wiedzę powodu by strasznie na niego psioczyć. Dobrze jest go mieć pod ręką do prototypowania. Własny string ma sens w specyficznych przypadkach, gdy potrzebujesz UNICODE albo masz własny system zarządzania pamięcią i nie chcesz, żeby STL ci losowo mazał po pamieci a z pmr nie chcesz, albo nie opłaca ci się bawić.