Забавный но досадный глюк

[runewalsh]

Так вы про эти конверсии. Если функция создаёт строку, а не пользуется переданной, то аллокация подразумевается сама собой, иначе и быть не может. С чего вы взяли, что с другими будет "в 2-4 раза меньше", когда вся память — это те самые исходный и результирующий буферы? В варианте же с внешними буферами — Utf8ToUnicode(Dest, Source, MaxChars) — аллокаций и правда нет.

[alexey38]

Не подменяй понятия. UTF-8 — представление исходной строки в памяти. Идея не в том, чтобы нагло считерить, прочитав UTF-32, а в вычленении символа, чтобы с ним можно было работать. Всё равно что прочитать в регистр. Или предлагаешь наложить искусственные ограничения на реализацию?

Вы сами подменили условия теста. Тест был в скорости получения символа, или в получении нескольких символов. Вы получили число в UTF-32, вместо символа в UTF-8.
Если изменить условие задачи в тесте, где вместо сравнения символа с пробелом нужно выполнять иные действия, как с символом, например, прибавить его к другой строке, то эта функция (UTF8CharacterToUnicode) у Вас не будет работать. Реальный код он не похож на этот тест. Так вот в реальной задаче под UTF8 придется каждый раз под частный случай писать свой вариант алгоритма, чтобы отстать всего в 2-10 раз. В UTF32, как и в AnsiString индексный доступ к символу применим для любого случая. UTF32, как и AnsiString будет всегда быстрее UTF-8.

Добавлено спустя 3 минуты 28 секунд:

Кот бы говорил про упёртость, везде тестировалось сравнение с #32.

Но Вы преобразовали символ UTF8 в код UTF32, тем самым исказили задачу. Мошенники всегда умеют доказывать правильность своего обмана.

Добавлено спустя 6 минут 8 секунд:

но для меня загадка, почему тормозит рандомный текст.

Потому, что в нем символов UTF8 длиннее 1 байта более 50%, и около 10% более 2 байт (т.е. 3 байтовые символы).

[runewalsh]

Потому, что в нем символов UTF8 длиннее 1 байта более 50%, и около 10% более 2 байт (т.е. 3 байтовые символы).

Внимательнее. Японские символы — 3 байта, и ничего.

прибавить его к другой строке

Я использую её же или UTF8CharacterLength. Обращаю внимание, что частным случаем является как раз-таки индексированный доступ, в случае с юникодом применимый только к UTF-32 — иначе предположение, что индекс символа совпадает с его смещением в единицах базового типа, неверно, и эта ошибка распространена в реализациях UTF-16 (см. всё ту же ссылку). И индексы ты используешь только потому, что разработчики языка не посчитали нужным вводить итераторы.

Слушай, ты, может, и linked list не используешь, потому что пытаешься индексировать и ноешь, что тормозит? Повторяю ещё раз, произвольный доступ к строке не нужен (любая обработка предусматривает поиск обрабатываемого куска), а скорость последовательного слишком сравнима, чтобы вносить оверхед по памяти, зависимость от endianness и вообще заменять тип строк.

[debi12345]

произвольный доступ к строке не нужен (любая обработка предусматривает поиск обрабатываемого куска)

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

ПС:
Отсылка на "реальный текст" ничуть не валиднее чем отссылка на сбои индексного доступа в QT (точнее на баги 100% надежного алгоритма, которые лдолжны быть устранены)

[runewalsh]

А если строка размеченена на фоагменты и нужнео моментально перейти на нужный

1. Строим индекс.
2. ???
3. PROFIT!!!
Серьёзно, никто не мешает во время разметки запомнить и номер символа, и смещение данных.

[alexey38]

индексированный доступ, в случае с юникодом применимый только к UTF-32

Так речь именно о том, что UTF-32 - это правильный тип строк, но в Лазаре он не реализован в должном объеме.
Сегодня UCS4String - это обычный массив целых чисел и не более. А строковые типы String, AnsiSntring, UnicodeString - у них есть множество функций для работы с ними.
Сегодня UTF-32 не доведен до удобства на уровне стандартной библиотеки. А это нужно, это востребовано, а любители UTF-8 препятствуют этому.

[debi12345]

и номер символа, и смещение данных.

А если какой-то из предшествующихз символов заменен на символ например другой длины ? Не просто же так UTF8 в разы проигрывает на манипуляцих.

ПС:
Я есть большой фанат UTF8, но как формата ХРАНЕНИЯ текстовых ФАЙЛОВ. В других областях (манипуляции, отображение,..) этой кодираовке не место - потому что она подразумевает тяжеловесные манипуляции буквально при каждом прикосновении.

[alexey38]

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

Итератор - это внешняя обертка и не более. Это удобство и лаконичность кода, но это не есть алгоритмический способ быстрого доступа. Наличие итератора для символов UTF8 сделало бы код более компактным и лаконичным, скрыв весь лишний код внутрь реализации итератора, но быстродействие от этого бы не повысилось.

Добавлено спустя 3 минуты 7 секунд:

произвольный доступ к строке не нужен

Смешно, когда малоопытная молодежь гнет пальцы веером, говоря о своем великом опыте. Вы свой узкий опыт пытаетесь выдать как некую фундаментальную истину.

[runewalsh]

А если какой-то из предшествующихз символов заменен на символ например другой длины?

Фиксим индекс. Понадобится структура данных с логарифмической сложностью изменения, но для подобной обработки она понадобится вам всё равно. Notepad++ практически одинаково тормозит на загрузке и редактировании больших файлов с любой кодировкой.

Смешно, когда малоопытная молодежь гнет пальцы веером, говоря о своем великом опыте.

Опытный дядька слишком опытен, чтобы привести пример истинно произвольного доступа, ага.

но быстродействие от этого бы не повысилось.

Естественно, речь о реюзабельности кода. Доступ к итератору — по определению O(1), а индексирование в общем случае не является его синонимом.

[alexey38]

а скорость последовательного слишком сравнима, чтобы вносить оверхед по памяти, зависимость от endianness и вообще заменять тип строк

Еще раз повторюсь, что скорость одного вызова функции UTF8Length(utf8) неприемлемо медленна для тех объемов, для которых имело бы смысл экономит память. Хоть итераторами, хоть какими-то иными извращениями Вы не заставите код быстро работать на UTF8. UTF8 имел смысл во времена DOS, когда 640 кБ ОЗУ. Сегодня UTF8 архаизм.

[runewalsh]

скорость одного вызова функции UTF8Length(utf8)

Если ты вздумал что-то делать с UTF8Length() символами, сложность твоего алгоритма никак не меньше O(N). А значит, эта функция её не изменит.
Опять же, различай длину и аналог концевого итератора.

[alexey38]

Слушай, ты, может, и linked list не используешь, потому что пытаешься индексировать и ноешь, что тормозит?

Главное, что существует наследуемый код. Применение типов UTF32 сохраняет наследуемый код в 100% объеме, за исключением ассемблерных вставок. UTF8 вообще ни как не совместим с наследуемым кодом. Требуется переписать абсолютно все, вообще все. Бесплатный Лазарь с его базовым UTF8String делается золотым, по сравнению с платной Дельфей. Перевести серьезный проект на UTF8String будет стоить, например, 1 млн.бакосов, это бред, а не тип данных.

Добавлено спустя 2 минуты 28 секунд:

Опять же, различай длину и аналог концевого итератора.

Молодежь, умейте сами различать, а не только пальцы гнуть. Я понимаю, что Вы извращенец, и пытаетесь доказать что Вы не просто извращенец, а Вы матерый неизлечимый извращенец. Кому это надо? Детское самолюбие?

Добавлено спустя 2 минуты 27 секунд:

Опытный дядька слишком опытен, чтобы привести пример истинно произвольного доступа, ага.

Потому, что пальцегнутая молодежь сама ничего не желает изучать. Не способна ни на что, кроме извращений. Хочешь учится - иди учись. К чему эти глупые вопросы с просьбой привести примеры. Если своих мозгов нет, то и примеры не увеличат.

Добавлено спустя 3 минуты 7 секунд:

Серьёзно, никто не мешает во время разметки запомнить и номер символа, и смещение данных.

Гениальное изобретение, достойное извращенцев. Вы предлагаете делать якобы компактный UTF8 строковый тип, но дополнительно к каждому символу создать массив 32 битных индексов, где хранить смещение символов?

Добавлено спустя 58 секунд:

Фиксим индекс. Понадобится структура данных с логарифмической сложностью изменения, но для подобной обработки она понадобится вам всё равно.

Маразм крепчает. Вы еще молодой, а уже старческий маразм. Как же так?

[runewalsh]

Странно, что опытному дядьке приходится объяснять (и повторять) очевидные вещи, но так уж и быть. Ключевая фича UTF-8 — бинарная совместимость с (7-bit) ASCII. Благодаря этому сторонняя либа может вообще не париться с кодировкой строк, а обрабатывать их как последовательности байт. Пример — Lua (да-да, парсер и прочие нетривиальные вещи в комплекте), где все строки "8-bit clean" — т. е. спецификация вообще не завязывается ни на какую кодировку, просто декларирует совместимость со всеми, где размер базового типа — 1 байт. Так многие делают — куда проще, чем вводить варианты (контрпример — WinAPI, что изящнее?).

дополнительно к каждому символу создать массив 32 битных индексов, где хранить смещение символов?

Ты это серьёзно, лол? Вообще представляешь, о каком "индексе" я говорил и сколько он занимает по сравнению с индексируемыми данными?

извращенец
маразм

Я ж не виноват, что ты (как, впрочем, и язык — я люблю паскаль, но говорю как есть) не дорос до предлагаемого уровня абстракции. -_-"
И не маразм, а эффективные алгоритмы. Они всё-таки не кьюсортом ограничиваются.

[debi12345]

Notepad++ практически одинаково тормозит на загрузке и редактировании больших файлов с любой кодировкой.

Потому что он есть ТЕКСТОВЫЙ редактор, при загрузке тупо конвертящий любой файл в UCS-2 (а значит одинаково тормозя при редактировании). Я тоже считаю это оптимальным решением.
И Мартин (автор МСЕ) тоже к этому (файлы в UTF8, обработка в UCS-2) пришел - хотя тоже долго и безуспешно пытался добиться вменяемого перформанса с виджетной UTF-8.

[runewalsh]

ТЕКСТОВЫЙ редактор, при загрузке тупо конвертящий

Ну с этим погорячился, да.