>>1182002 (OP)
Разметка епт
10+++++++ - старшие
11+++++++ - хвост

>>1182002 (OP)
>Кто додумался поставить лимит в 4 байта?
4 байта хватит всем!

>>1182002 (OP)
>Сколько раз веб крутанётся на хую, если со временем число известных человечеству символов преодолеет миллион?
А нехуй было эмоджи вводить

>>1182133
Как будто я виноват. Прилетят планетяне со своими азбуками, куда их пихать?

>>1182136
>куда их пихать?
Инопланетян? В багажник.

UTF-8 лишь подмножество юникода.

>>1182002 (OP)
Вероятно чтобы сделать предсказуемой аллокацию. Читая первый октет ты уже знаешь сколько байт занимает символ. Более того, нельзя заебенить символ занимающий более 32 бит, с твоим вариантом будут всякие buffer overflow.

>>1182417
Не будет там никакого буфер овервло, каждый новый байт тупо сдвигается влево и добавляется к одному и тому же 32-битному числу.

2оп: все верно, вся наша история это криворукие дебилы, которые далее сиюминутного практического применения помыслить не в состоянии. Утф с наркоманским кодированием. Жысон с кавычками, без комментов и с ебучей запятой. Сгмл-производные высеры, приправленные легасями из браузеров. SQL, который не умеет в не-inplace определения. GraphQL, который может все, кроме блять самих графов. И никто, никто сука, нихера не думает и не делает с этим.

>>1182417
> уже знаешь сколько байт занимает символ
Смысл? Если бы он стоял первым октетом, давал бы выигрыш. Но он стоит уже вторым, а минимальна длина - один.

>>1182002 (OP)
>Кто додумался поставить лимит в 4 байта?
Лол. В схеме кодирования UTF-8 — лимит 6 байт. А 4 байта решили считать максимальной валидной последовательностью из-за того, что этого достаточно для кодирования текущего стандарта юникода.

>>1182478
> никто не делает
Все привыкли юзать костыли, писать костыли, исправлять костыли костылями, костылять костыли для костылей. Говнокод проще и быстрее, главное, что работает.
© Вовка

>>1182478
>все верно, вся наша история это криворукие дебилы, которые далее сиюминутного практического применения помыслить не в состоянии. Утф с наркоманским кодированием.
utf-8 — нормальное кодирование.
А вот UTF-16 во всяких Windows и java это именно что дерьмо, которое было создано для сиюминутного практического применения: вау, двух байт хватит всем, давайте ограничимся двумя байтами и побыстрее продадим наш высер с шильдиком "unicode enabled".

>>1182488
Всякие японские кодировки изначально были 16-битные. У толстых букв и впоследствии уникода оттуда ноги и растут, iirc. Но для уникода дерьмо, да, тут спорить не с чем. В итоге каждая программа на винде и жабе текст читает в utf-8, конвертирует в utf-16, мутит-хуютит и снова конвертирует в utf-8, чтобы на диск/в сокет отправить. Долбоебизм сравнимый с майнингом.

>>1182002 (OP)
Prefix code: The first byte indicates the number of bytes in the sequence. Reading from a stream can instantaneously decode each individual fully received sequence, without first having to wait for either the first byte of a next sequence or an end-of-stream indication. The length of multi-byte sequences is easily determined by humans as it is simply the number of high-order 1s in the leading byte. An incorrect character will not be decoded if a stream ends mid-sequence.
Self-synchronization: The leading bytes and the continuation bytes do not share values (continuation bytes start with 10 while single bytes start with 0 and longer lead bytes start with 11). This means a search will not accidentally find the sequence for one character starting in the middle of another character. It also means the start of a character can be found from a random position by backing up at most 3 bytes to find the leading byte. An incorrect character will not be decoded if a stream starts mid-sequence, and a shorter sequence will never appear inside a longer one.
Sorting order: The chosen values of the leading bytes and the fact that the continuation bytes have the high-order bits first means that a list of UTF-8 strings can be sorted in code point order by sorting the corresponding byte sequences

Маняврируй

>>1182495
Манявыкладки фантазера-проектировщика (или вообще подогнали rationale под то, что сотворили). Поточный декодер можно так написать, что он будет жрать октеты опа до границы буфера, а если не хватило, ну чтож, хватит в следующий раз, частичный поинт никуда не делся.
>instantaneously decode
Чушь ебаная, у тебя либо хватает октетов, либо нет. Нет никакой разницы, сразу ты это узнал или по ходу дела.
>self-sync, sort-order
Сохраняется.

Давай скопипасть еще умных английских слов.

>>1182495
>>1182502
Я кстати допустил одну ошибку, либо находишь, либо нахуй из треда, ебаная макака.

>>1182002 (OP)
> Он логичен, не спорю, но почему длина статична? Вместо единственного бита-маркера в хвостовом октете сжирается половина старшего.
А как ты собрался детектить потерянные байты?
> Сколько раз веб крутанётся на хую, если со временем число известных человечеству символов преодолеет миллион?

Ни сколько. utf-8 кодирует до 2³¹ > 2 млрд. символов.

>>1182506
Нахуй их детектить, ты че, детектив?
>2³¹ > 2 млрд
Уже нет, лол

Короче, оп, раз этот пидор бездарно слился, палю наш проеб.
Твоя кодировка не будет сортироваться так же, как если бы ты все представил 32-битными символами. В утф-8 чем больше код, тем больше этих единиц в начале, соответственно символы возрастают как по значению, так и по закодированной последовательности. У тебя такого нет, и сортировать строки без декодирования не получится.

>>1182502
Нахуй пшел, школнег

>>1182506
>А как ты собрался детектить потерянные байты?
А он не собрался, этой жабамакаке похуй и на границы символов тоже, мамка же всегда оперативки докупит

>>1182488
Что в винде, что в джаве, два байта на символ зародилось в 1988-1990, utf-8 же только в 1993 был представлен
>>1182491
utf-8 удобен только тем, что восьмибитный ascii поддерживается из коробки и тем, что в куче сценариев он занимает минимум места (но не во всех). Во всех остальных сценариях он сосет с проглотом, потому что невозможно нет произвольного доступа к символам строки из-за переменной длины, в итоге все стандартные операции работают не за O(1) а за O(N)

>>1182945
>нет произвольного доступа к символам строки
А зачем он нужен?

>>1182478
>Жысон с кавычками, без комментов
И без ассемблерных вставок. Пиздец.

>>1182002 (OP)
>Кто додумался поставить лимит в 4 байта?
ем 16 миллионов символов мало, ну охуеть, двачеры, съебываемся тут реальные дядьки оказывается сидят, не то что мы
пиздец, что за капча нынче пошла

>>1183252
>съебываемся тут реальные дядьки оказывается сидят
Каникулы

>>1182951
>все стандартные операции работают не за O(1) а за O(N)
>А зачем он нужен?
Вы тут с фронтендов?

>>1183262
Джвачую, ОП тупой школопидораха

>>1182161
Юникод - это таблица символов, UTF-8 - это кодировка, то есть как эти символы представляются в памяти компьютера. Откуда ты такой идиот вылез?

>UTF-8
>подмножество юникода
Скотина тупая, пиздец...

>>1183252
>>Кто додумался поставить лимит в 4 байта?
>ем 16 миллионов символов мало
В UTF-8 4 байта кодируют 21 бит.

>>1183266
> все стандартные операции работают не за O(1) а за O(N)
> из-за отсутствия произвольного доступа

Ну-ка, довен, расскажи, как тебе произвольный доступ в, например, UTF-32, позволит конкатенировать строки за O(1) вместо O(N)

>>1183282
Твой дегенеративный вспук никак не противоречит мной сказанному, ебло тупорылое, сдристни нахуй отсюда чушкарь

>>1183314
Алсо, ты ещё и сказал хуйню, т.к. если уж придираться к словам по максимуму, то юникод - не таблица, а стандарт кодирования. Юникод != таблица символов Юникода, это разные понятия. Ещё разок псыкнул тебе не еблинский.

>>1183316
---> >>1183282

>>1183298
Ты мне сначала длину строки в UTF-8 найди за O(1)
пок-пок введем дополнительное поле для длины, потом сделаем replace(char,char) и соснем с реаллоцированием даже у изменяемых строк.
С индексированием что substring, что concatenate не требуют сканирования строки, поэтому можно просто memcpy, который почти что O(1)ибо бесконечность недостижима, а множитель настолько мал, что выходи o(сканирование)

>>1182506
>А как ты собрался детектить потерянные байты?
Где ты потерянные байты детектить собрался? В протоколах в которых и так контрольная сумма передается вместе с информацией?

>>1182526
>мамка же всегда оперативки докупит
Про сжатие кэша не слышал?

>>1183509
Сначала:
> ТЫ ТУТ С ФРОНТЕНДА? ВСЕ СТАНДАРТНЫЕ ОПЕРАЦИИ РАБОТАЮТ ЗА O(N) ВМЕСТО O(1) ИЗ-ЗА ОТСУТСТВИЯ ПРОИЗВОЛЬНОГО ДОСТУПА!

Теперь:
> ЭТИ СТАНДАРТНЫЕ ОПЕРАЦИИ НЕ ЗАВИСЯТ ОТ ПРОИЗВОЛЬНОГО ДОСТУПА!

>Ты мне сначала длину строки в UTF-8 найди за O(1)

Принеси real world задачу, где это нужно. Произвольный доступ и поиск длины строк это задачи уровня laba1.

>>1183516
Регексы и с небольшой натяжкой парсинг грамматик там вероятно можно как extended ASCII обрабатывать.

>>1183513
Штоу?
Такс, если не наркоманить (строки на линкованых листах и словарях), то реализация строки в памяти - это массив fixed-size элементов-символов (байт для ascii, два байта для utf16, не видел в природе utf-32 и неигнорирование суррогатных пар из коробки, окромя специальных классов для текстовой обработки). Где-то тут рядом торчит длина этого массива (как часть массива в C#,Java не вспоминаем про compact strings, либо перед байтами данных в памяти аки BSTR, zero-terminated strings поминаем лихим словом и не утекаем вместе с памятью).
Самые популярные операции:
1)Длина строки. Просто берем сохраненный размер - O(1). В случае utf-8 же надо прочитать всю строку и постоянно проверять является ли текущий байт символом либо куском символа, нааккумулировать количество символов - итого O(N)
2)Взятие символа по индексу. Читаем arr +(N-1) за O(1) вместо сканирования первых N-1 символов
Кроме большой сложности, вышеперечисленные операции сильно страдают с utf-8 из-за misaligned reading.
Далее же идут операции, которые вышеперечисленные используют.
3)Сравнение - очевидно если требуется прочитать O(N) в любом случае, то ниже чем O(N) не получишь. И это даже для тупенького ординального, с культурно-специфичным нужно еще проводить трансформации к каноничным формам - так что тут utf-8 vs fixed size не роляет
4)Подстрока - с позиции n взять m символов - memcpy(target,arr +n,msizeof(wchar_t)), не более чем O(m) - а в реальных условиях вполне себе o(m) - то бишь O(1). С UTF-8 надо просканировать все строку, чтобы понять где n позиция и где m символов кончаютсяЭкзотика с возвратом ссылки на старый массив/copy-on-write за O(1) выпилена и из Java, и из GCC
5)Trim/Ltrim/Rtrim/Contains/StartsWith/EndsWith/ToUpper/ToLower/Split - как и со сравнением, тут нужно читать - поэтому меньше чем за O(N) не выйдет
6)Concat - строго говоря работает напрямую с байтайми, memcpy в один массив, O(noOfElements) что у utf-8, что у fixed size
7)Replace - нужно читать, поэтому O(N), если строки неизменяемые - то результат нужно все равно аллоцировать. Если же изменяемые, то с fixed size все просто, а с utf-8 все равно нужно переаллоцировать ибо 3 байта вместо 1 хуй вставишь.
Кстати, никто не говорил про UTF-32, что в винде, что в джаве, что в шарпе используют UTF-16, а суррогатные пары учитывают только во вспомогательных классах, строки же втупую считают суррогатную пару за два символа и нет, это не UCS-2, а в некоторых ситуациях UTF-8 проигрывает UTF-16 в размере.
>>1183516
Если, ты собрался реализовывать рантайм/стандартную библиотеку как задачу уровня laba1, то тебе в npm пора свои наработки выкладывать, аки leftpad
На всякий случай, еще раз для дебичей, переменная длина символов в utf-8 лишает произвольного доступа к символам, и от этого большая часть операций, которые работали за O(1), работают за O(N). Это, блядь, нихуя не то же самое, что произвольный доступ превращает любой алгоритм за O(N) в алгоритм за O(1)

>>1183525
А почему ты думаешь что там голый byte/word array везде? Если строки иммутабельные, можно же рядом сложить длину строки, небольшой индекс по позициям символов (например для каждого десятого). Вот уже O(1) для длины строки, O(log N) для подстроки.

>Replace
>с fixed size все просто
А чё это просто? Ну символ на символ заменить ещё понятно. Но так-то можно же и строки разной длины друг на друга заменять. Будет такой же realloc/memmove.

>>1183525
>1)Длина строки. Просто берем сохраненный размер - O(1). В случае utf-8 же надо прочитать всю строку и постоянно проверять является ли текущий байт символом либо куском символа, нааккумулировать количество символов - итого O(N)
>2)Взятие символа по индексу. Читаем arr +(N-1) за O(1) вместо сканирования первых N-1 символов
>Кроме большой сложности, вышеперечисленные операции сильно страдают с utf-8 из-за misaligned reading.
>Далее же идут операции, которые вышеперечисленные используют.
>4)Подстрока - с позиции n взять m символов - memcpy(target,arr +n,msizeof(wchar_t)), не более чем O(m) - а в реальных условиях вполне себе o(m) - то бишь O(1). С UTF-8 надо просканировать все строку, чтобы понять где n позиция и где m символов кончаютсяЭкзотика с возвратом ссылки на старый массив/copy-on-write за O(1) выпилена и из Java, и из GCC

А какие, собственно, юз кейсы у голых memcpy, взятии символа по индексу и нахождении длины строки? Тебе же по любому нужно найти где именно у тебя подстрока находится, можешь сразу индексы в переменные скопировать и потом в тот же memcpy передать хоть для utf-8, хоть для utf-16.

>>1183525
>1)Длина строки.
Если тебе надо сохранить в базу данных с полем фиксированной длины, то тебе достаточно знать, сколько там байтов.
Если число видимых символов (grapheme clusters), то надо сканировать всю строку в том числе и в utf-32.
"Длина строки" в смысле code unit/code point практического смысла не имеет.

> 2)Взятие символа по индексу.
Задание из laba1. Практической такой задачи не встречается. В языках со встроенной поддержкой юникода (Swift, например) работают с grapheme clusters.

> операции сильно страдают с utf-8 из-за misaligned reading
Для байтов нет misaligned reading. Байт по любому адресу "выровнен".

> 4)Подстрока - с позиции n взять m символов
Опять задание из labaX.

>>1183535
А приведи пример где не голый byte/char array? В стандартной библиотеке/реализации рантайма, не в пет-проджекте. В C# - array двухбайтовых чаров, в Java - фккфн двухбайтовых чаров недавно завезли compact strings - строка может быть не из utf-16 char, а Latin1 byte -потому там byte array все сложно
В плюсах string, std::string - массив char, std::wstring - массив wchar_t, из-за гибкости определения char завезли еще std::u16string - массив char16_t, и std::u32string - массив char32_t
В Питоне было string - массив 1-байтовых char и unicode - массив 2-байтовых char, стал string - массив в зависимости от режима 1-байтовых,2-байтовых или же 4-байтовых символов.
В Javascript V8 - массив либо 1-байтовых, либо 2-байтовых символов.
>>1183537
Понимаешь хоть, что такое базовые операции, и что решения юзкейсов опираются именно на них? И если базовые операции не подходят для юзкейса - нужно их реализовать самому? Вот это вот копирование индексов в переменные - именно что своя реализация для substring. Хреновая сложность обычно выражается не в тот что у тебя взятие символа по индексу стало линейным вместо константного, а в том что триграмный поиск стал квадратичным вместо слинейного, или поиск string_similarity стал кубическим вместо квадратичного
>>1183567
>laba1,labaX
> В языках со встроенной поддержкой юникода (Swift, например) работают с grapheme clusters.
А, ты из этих пробитых, у которых substring даже не было несколько лет. И ось уходила в гости к Джобсу от нескольких символов девангари.
>Для байтов нет misaligned reading
UTF-8 не однобайтовая, если тебе для чтения нескольких байтов нужно прочитать каждый байт по отдельности - то ты получаешь ситуацию даже хуже чем misaligned reading. С UTF-8 как - можно понять длину символа по первому байту, а потом можно прочитать его целиком - но на может уйти как нормальное чтение, так и невыровненное, если символ пересек выравнивание.

>>1183743
>не голый byte/char array
Я не это имел ввиду, не заменить array, а рядом с ним структуры держать. Но тащемта в хаскеле строка это связный список например.

>>1183754
>Но тащемта в хаскеле строка это связный список например
Которым никто в реальной жизни не пользуется. Есть тип Data.Text (аж две штуки) + экстеншн OverloadedStrings.

>>1183515
> В протоколах в которых и так контрольная сумма передается вместе с информацией?
Это в каких же?

>>1183754
В теории то можно, но по факту никто не пользуется. В функциональщине неэффективные структуры вполне живут, за счет возможности доказать отсутствие говеных эффектов и литров пота, которые выделяют программисты GHC
Вся телега с compacted strings в HotSpot JVM была как раз про то, как уменьшить нагрузку на память - если только символы Latin1 то хранить в однобайтной кодировке. Если рядом с массивом держать еще и дополнительные структуры держать, то нагрузка только увеличится. Кстати, UTF-8 на самом то деле выигрывает в объеме только на символах из Latin1 и близлежайших, чтобы покрыть Basic Multilingual Plane из Unicode в UTF-16 хватает 2 байт, в UTF-8 же надо 3 байта. Японцы поэтому не особо рады UTF-8 лол, это ж типичный white privilege