Cyfry zamiast liter w wchar_t

Windows dla konsoli używa innego kodowania niż dla reszty systemu. I chyba przez to są problemy. Rozwiązało by problem przejście na po całości na uft-8

@carlosmay
Może jakieś zawiłości WinAPI na to nie pozwalają? Cholera wie dlaczego konsola domyślnie nie ma sensownego kodowania a to takie oczywiste że gdyby umieli to w M$ zrobić to już by tak było. :\

@mateczek
Pytanie dlaczego? Znaczy wszyscy wiedzą, dobre standardy gryzą.

EDIT:
Ale dobra, robię offtop, kiedyś założy się temat do narzekania na Windowsa. ;)

Pytanie roku, czy kiedyś Windows ogarnie się na tyle żeby dało się klepać znaki diakrytyczne normalnie w kodzie?

Przecież można. Wystarczy użyć czegoś, co poprawnie implementuje odczyt i zapis do/z konsoli, czym niestety std::cin i std::cout z powodów historycznych nie są i raczej nie będą.

Rozwiązało by problem przejście na po całości na uft-8

Po co, skoro Windows wszędzie, poza przestarzałymi funkcjami, używa UTF-16 (UTF-8 wtedy jeszcze nie istniało!), a konwersja między nimi jest gdzieś między "trywialną" a "bardzo prostą"?

Windows dla konsoli używa innego kodowania niż dla reszty systemu.

Konsola Windows domyślnie używa tego samego kodowania, co chyba każde API Windowsa, czyli UTF-16. Wersje *A funkcji API Windowsa istnieją tylko dla wstecznej kompatybilności i prawie zawsze są implementowane jako wrappery wokół odpowiadających wersji *W, które są wersjami zalecanymi i które faktycznie coś implementują.

Przecież można. Wystarczy użyć czegoś, co poprawnie implementuje odczyt i zapis do/z konsoli, czym niestety std::cin i std::cout z powodów historycznych nie są i raczej nie będą.

Z ciekawości – jakie to powody historyczne? Mnie to tam średnio obchodzi, mogę użyć czegoś innego albo w ogóle nie przejmować się Windą bo często nie muszę. Po prostu widząc, że coś na pierwszy rzut oka tak oczywistego nie działa jestem… zaskoczony?

Z ciekawości – jakie to powody historyczne?

"Windows" 1.0 i jego następcy, aż do "Windowsa" Me. Gdyby nie te potwory, to Windowsy — te prawdziwe, z linii NT — byłyby miłe, łatwe i przyjemne. I pewnie zamiast wrapperów dla obecnej strony kodowej, mielibyśmy obecnie wrappery dla UTF-8.

Windows NT od zawsze obsługiwał tylko Unikod. W NT 3.1 oznaczało to UCS-2, ponieważ Unikod kończył się wtedy na U+FFFF, a UTF-8 nie istniało, gdy ten system powstawał; w 2000 zaczęli wspierać UTF-16, bo obsługuje pełny Unikod i jest rozszerzeniem UCS-2.

Niestety, "Windowsy" nigdy nie obsługiwały Unikodu, a były komercyjnym hitem. Tam wszystko jechało na obecnej stronie kodowej[1], przez co jakiekolwiek porządne i18n i l10n było problemem, ale nikt się tym za bardzo nie przejmował.

Żeby programy z "Windowsów" można było łatwo portować na Windowsy (portować? Wiele programów po prostu działało bez zmian!), to Windowsy otrzymały funkcje korzystające z obecnej strony kodowej, które konwertowały wszystkie stringi do Unikodu i przekazywały je do właściwych implementacji. Gdyby nie ta kompatybilność, to przejście z "Windowsów" na Windowsy chyba nie byłoby możliwe.

Ponieważ "Windowsy" dominowały, to typowe programy były pisane przede wszystkim pod nie, więc korzystały z kodowań w rodzaju Windows 1250 (a w konsoli np. CP852). Problem w tym, że inercja sprawiła, że programy były pisane w ten sposób nawet po tym, gdy "Windowsy" zostały wyparte na dobre przez Windowsy, kiedy to już przestało mieć większy sens; niestety, inercja się nie przejmuje sensem, skoro ktoś zawsze tak pisał, a wciąż to działa, to po co to zmieniać?

Twórcy bibliotek standardowych w teorii mogliby zmienić to zachowanie i dostarczyć std::cout i rodzinkę, które pod Windowsem przyjmują UTF-8, tłumacząc go po drodze na UTF-16 dla WriteConsoleW (analogiczna konwersja w drugą stronę dla ReadConsoleW). Ale nie chcą, bo wiedzą, że dziś wszyscy wiedzą, że std::cout nie działa i obchodzą to na różne sposoby, jak np. krążąca po tym forum i nie tylko funkcja PL. Gdyby naprawić std::cout, to takie hacki przestałyby działać. Większość osób nie pomyślałaby "o, fajnie, teraz std::cout używa UTF-8", tylko "mój program działał z poprzednią wersją a teraz nie działa, Microsoft to [CENSORED]".

tl;dr: bo Windows 95.

Na całe szczęście, toolkity w rodzaju Qt najczęściej zachowują się jak trzeba i używają funkcji *W.

[1] Tak naprawdę obecnych stron kodowych jest więcej niż jedna. Przykładem czegoś, co posiada własną, osobną obecną stronę kodowę jest właśnie konsola.