> Они объясняют, почему так, и эти доводы разумны.
> 1) Большинство внешних текстовых данных -- или UTF-8, или ASCII (подмножество UTF-8).
> Тратиться на перекодировку при вводе/выводе жалко.Тратить время на перекодировку при вводе и выводе как раз совершенно не жалко.
Это делается один раз. А вот времени на перекодировки по требованию
происходят несоизмеримо большее число раз во время выполнения приложения.
Например, при сопоставлении с теми же регекспами. Лишний расход на пустом месте.
> 2) Большинство простых операций со строками
> (итерация, поиск символа или подстроки, разбивка,
> определение класса символа в ASCII) прекрасно работают с UTF-8, и даже
> проще и быстрее, чем с UTF-32 (достаточно таблицы 2^8 для классификации
> и преобразования регистра в ASCII).
Точно так же, прекрасно все работает и для строк, представленных
в виде wide символов. Не вижу никаких выгод.
> 3) Большинство сложных операций со строками (сортировка, переносы, изменение регистра
> в странных алфавитах) всё равно требуют учёта национальной специфики (локали), это
> очень сложная и дорогая задача, накладные расходы на раскодирование UTF-8 на
> этом фоне мизерны. И в UTF-32 не будет проще, всё равно
> нужно учитывать комбинированные символы и т.п. Это если делать на совесть.
> Иначе см. п. 2.
И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время, которое так экономили в п.1.
> 4) Если так уж нужно работать с UTF-32 -- пожалуйста, распакуйте в
> vec[char] (char 32-разрядный), потом запакуете. Накладные расходы те же, что и
> неявные при языковых строках в UTF-32, только вы их контролируете.
А заодно перепишите все уже имеющиеся системные и сторонние библиотеки.
> 5) Аналогично, если нужно работать без перекодировки с внешними данными в другой
> кодировке -- вектор октетов и никаких накладных расходов.
Накладных расходов на память нет. Это миф.
Несоизмеримо больше занимает то, что никак не связано со строками.
