>> Тратить время на перекодировку при вводе и выводе как раз совершенно не
>> жалко.
>> Это делается один раз.
> Два раза. На каждый обработанный байт. При вводе и выводе. И много
> раз, если нужно одни и те же данные выдавать по запросу
> много раз. Мелочь, но зачем делать лишнюю работу?Однократный ввод и вывод -- абсолютная мелочь,
на которую даже не стоит обращать внимания.
>> А вот времени на перекодировки по требованию
>> происходят несоизмеримо большее число раз во время выполнения приложения.
>> Например, при сопоставлении с теми же регекспами.
> Не надо. Регэкспы, рассчитанные на UTF-8 работают с тем же успехом, что
> и рассчитанные на UTF-32. Даже лучше, потому, что байтов нужно вчетверо
> меньше прогнать. И проверки проще.
Нет. Регекспы, расчитанные на ucs4 работают лучше, потому что
автомат получается меньше, в нем меньше переходов, кроме того,
он легче минимизируется, больше возможностей, к примеру, двумя числами представить
[from..to], больше шансов "склеить" входные веса переходов и т.п.,
соответственно автомат меньше занимает места в памяти и быстрее работает.
Выигрыш значительный и по скорости и по памяти. Поэтому вход нужно каждый раз
перекодировать из utf-8 в ucs4 и обратно, если в качестве внутреннего представления
строк выбран utf-8. Простейший пример: (латинское_А|русское_А|японский_иерогриф).
В случае utf-8 он будет иметь 6 переходов и 7 состояний. В случае ucs4 -- два перехода
(или вообще 1, если использовать мепку входных весов) и два стостояния.
Ну а в случае использования character classes разница будет просто невероятная.
Один переход + map в случае ucs4 против я даже
не знаю скольки переходов в случае utf8.
>> Точно так же, прекрасно все работает и для строк, представленных
>> в виде wide символов. Не вижу никаких выгод.
> Это о том, что у UTF-32 нет выгод перед ASCII/UTF-8. А вот
> недостатки есть. Поиск цифры [0-9] или начала идентификатора [A-Za-z_] в ASCII
> -- всего лишь одна табличка,
И в ucs4 одна табличка, малюсенькая, с указанием ее минимального и максимального индекса.
Если проблема и есть, то явно не в том месте.
>> И здесь мы опять получаем необходимость перекодировку по требованию, теряя драгоценое время,
>> которое так экономили в п.1.
>> А заодно перепишите все уже имеющиеся системные и сторонние библиотеки.
> У вас системные и сторонние библиотеки на UTF-8 или на UTF-32 рассчитаны?
> Подозреваю, что на первое чаще. А ещё есть UTF-16. Перекодировать всё
> равно иногда придётся, так лучше уж делать это реже.
У нас системная библиотека имеет char и wchar_t-based API, причем первая реализована через вторую. Поэтому да, перекодировать желательно как можно реже,
а не туда и потом еще и обратно ;-)
>> Накладных расходов на память нет. Это миф.
>> Несоизмеримо больше занимает то, что никак не связано со строками.
> Тут скорее не на память, а на перекодировку. Если нужно найти в
> файле "\nFrom ", то в любом случае вы работаете с неперекодированными
> байтами.
В этом конкретном случае при использовании ASCII-совместимой кодировки для ввода-вывода
перекодировка заключается лишь в том, чтобы переложить char в int.
Пользователи Shift-JIS и им подобных сами себе буратины.
