Даарийский Круголѣтъ Числобога для андроида

Я не страдаю. Это у юзеров юникода wchar_t жрёт в линуксах по 4 байта на каждый (!) символ включая ASCII (!!!). Enjoy your UTF-32 даже если это UTF-8. Можно, конечно, всё равно пытаться юзать char вместе с UTF-8, только вот тут возникают проблемы работы с подстроками, поскольку каков размер в байтах следующего символа - неизвестно. А, может, это вообще не символ а модификатор к символу. В однобайтных кодировках таких проблем с неоднозначностью нет.

Это у юзеров юникода wchar_t жрёт в линуксах по 4 байта на каждый (!) символ включая ASCII (!!!). Enjoy your UTF-32 даже если это UTF-8. Можно, конечно, всё равно пытаться юзать char вместе с UTF-8, только вот тут возникают проблемы работы с подстроками, поскольку каков размер в байтах следующего символа - неизвестно. А, может, это вообще не символ а модификатор к символу. В однобайтных кодировках таких проблем с неоднозначностью нет.

А тебе-то что? Или ты быдлокодер и пишешь софт, которому для работы жизненно необходима однобайтовая кодировка?

Как это «что»? Это неэкономное использование памяти. И мне это неприятно дважды: и как юзеру, и как разработчику. В одну и ту же оперативку может поместиться в 4 раза больше одного и того же текста в char/KOI8-R чем в wchar_t/UTF-8. Да и при записи в текстовые файлы те символы, которые не входят в ASCII, будут жрать в 2 раза больше дискового пространства. Также я там выше описал отсутствие возможности нормальной работы с подстроками юникода в C. Конечно, для обычного юзера это неактуально, да и необязательно писать именно на C, и многие предпочитают писать на разных Python'ах, но...