> Тратить время на перекодировку при вводе и выводе как раз совершенно не
> жалко.
> Это делается один раз.Два раза. На каждый обработанный байт. При вводе и выводе. И много раз, если нужно одни и те же данные выдавать по запросу много раз. Мелочь, но зачем делать лишнюю работу?
> А вот времени на перекодировки по требованию
> происходят несоизмеримо большее число раз во время выполнения приложения.
> Например, при сопоставлении с теми же регекспами.
Не надо. Регэкспы, рассчитанные на UTF-8 работают с тем же успехом, что и рассчитанные на UTF-32. Даже лучше, потому, что байтов нужно вчетверо меньше прогнать. И проверки проще.
> Точно так же, прекрасно все работает и для строк, представленных
> в виде wide символов. Не вижу никаких выгод.
Это о том, что у UTF-32 нет выгод перед ASCII/UTF-8. А вот недостатки есть. Поиск цифры [0-9] или начала идентификатора [A-Za-z_] в ASCII -- всего лишь одна табличка, для UTF-32 же будет как минимум к этому ещё проверка/ветвление (десятки процентов к производительности). Для не-ASCII будет в обоих случаях сложно, но в UTF-8 всё же типичные данные будут короче.
> И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время,
> которое так экономили в п.1.
Так и в UTF-32 перекодировка нужна. Для всяких там комбинированных символов. Не говоря уж о том, что распаковка из UTF-8 -- это 1-3 ветвления, а дальше в подобных задачах этих ветвлений и обращений к таблицам будут десятки.
> А заодно перепишите все уже имеющиеся системные и сторонние библиотеки.
У вас системные и сторонние библиотеки на UTF-8 или на UTF-32 рассчитаны? Подозреваю, что на первое чаще. А ещё есть UTF-16. Перекодировать всё равно иногда придётся, так лучше уж делать это реже.
> Накладных расходов на память нет. Это миф.
> Несоизмеримо больше занимает то, что никак не связано со строками.
Тут скорее не на память, а на перекодировку. Если нужно найти в файле "\nFrom ", то в любом случае вы работаете с неперекодированными байтами.
