Я забыл вычесть координаты точки до смещения.
>>644546
Блендор.
Вообще в идеале твой парсер должен уметь работать, не имея всю строку в памяти, а читая куски по мере необходимости. Я себе сделал гибридный вариант:
— У парсера есть поля s: StringView (текущий буфер) + sp: SizeUint (позиция в буфере), через которые ты можешь удобно работать с куском текста в памяти. 99,8% времени этого достаточно; типичная ситуация — это тебе нужно прочитать число из 4 цифр, при этом sp = 1000, а s.n (размер буфера) = 65536, то есть всё число присутствует в памяти, и для осуществления желаемого можно так же, как с единственной строкой, натравить стандартную функцию преобразования строки в число на 4 символа в буфере, s.chars[sp..sp+3].
— Если ты достигаешь конца буфера (нужно прочитать число, но sp = 65534 и s.n = 65536 — доступны только 2 символа, и все они являются цифрами, так что неизвестно, это всё число или нет), ты вызываешь функцию ReadMore, которая читает новый блок — и, если нужно (если sp < s.n), переносит хвост старого блока, начиная с sp, в начало нового. Так что после неё s.chars[sp] продолжает указывать на начало числа, и в конце концов ты всё-таки заимеешь всё число в памяти, сведя случай к предыдущему.
Например, при разборе текста «someNumber = 1234; someOtherNumber = 5678» до ReadMore ситуация может быть
>s = "someNumber = |12"
(где | — позиция sp.)
После ReadMore она станет
>s= "|1234; someOthe"
— s[sp] продолжает указывать на начало числа, а части перед sp полагаются больше никого не интересующими и разрешёнными для отбрасывания.
Я не знаю, у меня проблемы с мозгом. Ну точнее знаю. Что они есть.
Я вообще не понима, неужели нет никакого нормального способа перестать быть лоу айкью дауном.
Я не знаю, я постоянно на подобное напарываюсь, и можно было бы списать на то, что софт слишком сложный, чтобы избегать даже таких очевидных проблем, что это и не проблемы вовсе, а я просто придираюсь, но я сейчас задумался, что я так-то сам часть проблемы, потому что я в жизни своей никогда не создавал никаких баг репортов после того, как напарывался на подобные вещи. Ну я на английском просто плохо говорю ещё, умереть хочется, короче.
Я не знаю, что делать с таким критическим падением айкью, мне плохо, постоянно какие-то нечитаемые ошибки с борров чекером, я устал, я хочу подохнуть. Я не чувствую, что пишу то, что хочу, я чувствую, что пишу то, что хочет rustc. Вот, небольшой кусок мусорного кода https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d997d44761f61669b3546aa13ee3c7bf я хотел сделать, чтобы advance мог скипать байты, если он выходит за границы того, что уже прочитано. Я не понимаю, как это сделать без чтения ненужных байтов в буфер и без io::Seek. Окей, есть io::copy и io::sink(), попробовал переписать https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d6593f809fcc6f260a0d6f0e39db994c всё у меня слишком маленький айкью, чтобы понять, а что не так, зачем take мувает внутрь себя источник, откуда он читает, что вообще происходит.
Что вот мне делать, переписать, чтобы он не сам читал, а у него спрашивали, что он хочет сделать: скипнуть байты, прочесть сколько-то байтов, и потом пушили в него байты что ли, но это же бред, а может лучше просто выпилиться, потому что жить с таким маленьким айкью это просто уже невозможно.
Если прописать use std::io::Read, то всё будет работать. Или если вместо
> self.source.by_ref().take(...)
писать
> io::Read::take(self.source.by_ref(), ...)
то тоже будет работать.
Я понятия не имею, почему так. Проблема, видимо, в том, что в трейте Read есть только take(self, ...). Но в этом файле std::io::impls https://github.com/rust-lang/rust/blob/9fa6b3c15758e85657d5be051cfa57022a8bbe57/library/std/src/io/impls.rs#L17 есть отдельно реализация трейта Read для &mut Read. Но почему он сам не может разобраться, что можно использовать реализацию из impls, я не понимаю.
Минимальный пример как-то так выглядит:
https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=46d6d0474f2dd91d1b0bc33de05225b5
>>668693
Проблема не столько в расте, сколько в слишком низком айкью, который ещё и продолжает уменьшаться.
У меня появилось в мыслях, что можно было бы маркерами сделать два отдельных типа и в них сделать две отдельных реализации одного и того же метода. Но там всё равно без макросов в итоге не обойтись для реализации остальных методов, которые не зависят от того, какие трейты реализованы, но хотят вызывать методы, которые от реализованных трейтов зависят https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477. Ну либо так https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=52707488453b2530ddf0d268a505c477 и я даже не знаю, что из этого хуже.
Но это даже не решение проблемы, что два отдельных типа приходится делать — это так-то бред.
А, ссылка https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=17e1b48d296eb1642af5bfae4dac8aad
Вообще ещё одна шизо-идея — это заставить самого пользователя реализовывать трейт Skippable. Сделать просто два макроса с двумя реализациями. Ну как, просто, там нужно будет как минимум заморочиться, если у структуры, для которой трейт реализуется, есть дженерик параметры, например. И вроде как вместе с min_specialization, которая вроде как по крайней мере не unsound, можно сделать одну дефолтную реализацию и пользователь может через макрос уточнить её https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=b878b49b9ef2210b03a6163e1c887f27. То есть в худшем случае используется дефолтная реализация.
>переписать, чтобы он не сам читал
Ну в смысле, что он не будет вызывать read, не будет владеть буфером, куда читает, а будет только по указателю, который ему дают. Наверное, это лучше, не знаю, потому что более гранулярное апи получится, которое проще переиспользовать и бла-бла-бла https://youtu.be/ZQ5_u8Lgvyk, но важнее, что мне тогда не приходится использовать трейты.
Ещё в предыдущем >>650387 варианте у меня в голове была какая-то стрёмная идея, что токенизатор должен по очереди пытаться распарсить токены, про которые он знает, и, наверное, я думал, что это сделает реализацию довольно прямолинейной и будет легко добавлять новые типы токенов, но по факту получился довольно нечитабельный код.
Во-первых, жсон токенизатор всё не должен беспокоится о валидности строк, чисел и ключевых слов по типу true или false, он просто должен проглатывать все эти вещи до следующей кавычки или до следующего разделительного символа. То есть опять же, более гранулярное апи, пусть пользователь сам разбирается с валидацией utf-16 булшита в жсон строках, что там с числами и так далее.
Ещё же тут дело в том, что если я читаю жсон, чтобы извлечь из него какую-то информацию, я, скорее всего, знаю, какая у него схема и поэтому мне необязательно нужно полностью его структуру в память сохранять. Возможно, я просто хочу получить только значения по какому-то конкретному ключу.
Во-вторых, у токенизатора должен быть контекст: находится он просто жсоне, внутри строки, числа и тд. И в зависимости от контекста он должен по-разному интерпретировать прочитанные символы. И менять контекст по ходу токенизации — это тоже ответственность пользователя: что после открывающей кавычки надо поменять контекст на строку, например.
В общем, токенизатор становится просто функцией от указателя на байты и текущего контекста.
https://godbolt.org/z/88Kfaj9os
Ну это в первом приближении, я просто хотел проверить, смогу ли я хотя бы прожевать тот же жсон.
Но что я так и не придумал, как решить — это как быть с бэктрекгингом. Предыдущий вариант состоял из него целиком и полностью, тут его гораздо меньше, но я не могу придумать, как его избежать полностью. Конкретно многострочные комментарии: когда встречаю звёздочку мне нужно либо сразу прочесть следующий символ, чтобы понять, это конец комментария или нет, либо запомнить, что я прочитал звёздочку и если после неё потом прочитаю слеш, то это конец комментария, либо читать многострочные комментарии кусками и придумывать какой-то дополнительный контекст для токенизатора, в котором он останавливается, если читает слеш, либо не хранить никакого дополнительного состояния параноидально при виде каждого слеша читать, что было перед ним.
Но это всё кривые решения, которые реализованы как какие-то исключения из правил, я хочу умереть.
Это типо эвристическая оптимизация, из предположения, что рядом с ASCII символами будут с большой вероятностью другие ASCII символы?
Ещё я как-то, мне надо было хотя бы немного пролистнуть RFC у UTF-8, потому что всё же, например, не любые три байта вида
> 1110xxxx 10xxxxxx 10xxxxxx
являются валидным код поинтом. Правда, я чего-то не знаю, почему так сделали.
https://www.rfc-editor.org/rfc/rfc3629#section-4
Например, E0 80 80 — это невалидный код поинт.
Я ещё заметил, что from_utf8 возвращает в ошибке то, до какого момента байты валидны, и там есть ещё unchecked версия, которая просто каст делает. Короче, наверное, лучше этим пользоваться, если использовать std в принципе, чем городить ту кривую ерунду, которую я написал выше.
Нашёл очень доступное для лоу айкью даунов объяснение про LR(0), SLR(1) и LR(1) парсеры:
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/100%20Bottom-Up%20Parsing.pdf
https://web.stanford.edu/class/archive/cs/cs143/cs143.1128/handouts/110%20LR%20and%20SLR%20Parsing.pdf
Но я не знаю, хватит ли у меня айкью, чтобы реализовать генерацию action/goto таблиц хотя бы для LR(0) грамматик, а LR(0)-парсинг, если что, это когда ты применяешь правило из грамматики к последовательности символов только лишь основываясь на том, какие символы ты успел прочитать, без учёта того, что за ними идёт. То есть, например, в такой грамматике, как я понимаю, невозможно нормально реализовать оператор постинкремента или operator[].
>>672094
Нет, короче, это бред, в этом JsonTokenizerMode нет никакого смысла, усложнение кода ради ничего, в итоге получается одна жирная функция, которая обрабатывает все ситуации, вместо нескольких небольших на каждую отдельную ситуацию, да, очень ГРАНУЛЯРНО, какой же я тупорылый даун. Так, всё, я перепишу нормально, как было с самого начала, только, возможно, без шизомакросов и всё же с фиксированным буфером, куда читается входная строка.
И со вторым тут две идеи: наивная - все кадры одинакового размера, прозрачный цвет на местах уже закрашенных пикселей, и вторая - попытаться разбить картинку на как можно больше непересекающихся прямоугольников, чтобы не хранить избыточные прозрачные пиксели. Как это сделать - не знаю, наверное, резать пополам пока не найдёшь прямоугольник, где мало цветов, и потом так же, разрезанием пополам пытаться присоединить к нему ещё прямоугольник, чтобы по возможности максимизировать количество цветов. Но я не уверен, что это будет работать лучше, чем наивная идея.
Вариация идеи с прямоугольниками - в глобальной таблице цветов сохранить все самые часто встречающиеся цвета и в первую очередь искать прямоугольники, где много цветов из глобальной таблицы, для которых использовать глобальную таблицу вместо локальных. Ну то есть попытаться сократить повторные цвета среди локальных таблиц. Но тут, мне кажется, это совсем переусложнённый вариант и он точно будет в реальности хуже наивного.
Я начал сегодня писать читалку гифок, но пока что не успел написать даже прогу, которая бы просто проглатывала гифку без разбора. Я постараюсь найти завтра время, чтобы хотя бы просто проглотить гифку.
С возвращением тебя.
>нужно, чтобы кто-то спас меня от такой жизни.
Однажды я курил с обычным пацаном с района, мы стояли и был обычный диалог гоп-стиль ни о чём. Я вижу как к нам идёт один казах, я думаю что он такой же как другой чувак, дескать типичный пацанчик с района и он так себя и вёл, пока я что-то не сказанул про античную философию...
Я люблю поговорить, но глубоких познаний у меня нëт ни в чём, этот казах меня раскатал как ребёнка. У него даже тон изменился, он стал настоящий когда мы начали говорить про философию. А выглядел как обычный "четкий пацан". Я тогда особого внимания не это не обратил.
Сейчас когда начал менять свою жизнь понял, что очень многие люди завидуют мне из-за моего интеллекта, чуствуют себя ниже и это задевает их самолюбие. Поэтому они пытаются меня клюнуть. Вот вчера выряс это с с силой из своей подружки. Я сам считал себя самым последним глупцом на свете, даже совсем не верил своему мнению. Но это потому, что меня всю жизнь подавляла мать, а отца не было, а на самом деле я как Никола Тесла, чуствую это.
А тот парнишка просто скрывал силу, ведь иначе люди не примут. Всегда появляются проблемы когда ты выше в обществе на порядок. Но говорить стоит не со всеми. Ты можешь просто не говорить с людьми или говорить с ними на их языке, как тот казах. Тогда они тебя примут, но главное внутри остаться собой. Поверь в себя.
Бог тебе в помощь.
Константные функции в трейтах в принципе нельзя использовать. Вызывать константные методы на не-константах нельзя. Передавать не-константы в константные функции (чтобы вывелся const дженерик с размером массива) нельзя даже, если эти не-константы в самой функции никак не используются. Доступ к константам, определённым, в трейте, есть только через типы, которые имплементируют трейт, но не через переменную этого типа.
В итоге я не знаю, как достать на этапе компиляции размер массива, мне кажется, это невозможно. В плюсах это можно сделать просто через constexpr метод, а здесь результат выполнения const функции считается константным только, если все аргументы у неё константные. Нужен хотя бы аналог decltype.
Вообще с массивами невозможно нормально работать из-за того, что слайсы теряют свой размер даже, если он известен: если array - это [T; N], то array[..] - это всё равно просто &[T]. Можно сделать .get(...).as_ptr().cast::<[T; N]>(), но проверки на то, что слайс не выходит за границы, похоже невозможно сделать в компайл-тайме из-за проблем выше.
Да, клиппи предупреждает, если слайс выходит за границы массива, но клиппи - это не компилятор, что там случилось с if it compiles, it works, это типо всё приколы и несерьёзно что ли. Причём просто доставание элемента по индексу, который выходит за границы - это rustc считает ошибкой, но если слайс выходит за границы - то уже нет.
И что, и какой смысл во всём этом тогда.
Позавчера вчера сегодня написал всё же что-то короче декодирование, но у меня нет сейчас доделывать, как есть в общем https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=fa66d48c734dcceb560a79a232760999 это какая-то дефолтная гифка с википедии, я не знаю, зачем я храню lzw коды в хештаблице, ну и бред, вот это эффекты низкого iq, но я не могу уже сейчас доделывать, я рандомно раскрасил, там даже яркость пикселей не вычисляется, я даун тупой
Я не понимаю, почему Rc<[u8]> не хочет становиться владеющим итератором, разве он не владеет данными, постоянно ошибки какие-то, что я ссылку на временное значение делаю. Я просто хотел из impl Iterator<Item = Rc<[u8]>> сделать impl Iterator<Item = u8>, но не выходит, не знаю. С вектором вместо Rc работает, а в чём принципиальная разница между ними - я не понимаю. Наверняка снова какой-то кринж раст момент, который где-то мельком упоминается, что ты какой-то трейт не импортировал или что-то в этом духе, и максимально бесполезное сообщение об ошибке, я бесполезное хочу подохнуть, мне испортили жизнь, руки чешутся что-нибудь разбить + сломать
Винда мусор, всё, она взяла сама по себе ночью всё позакрывала и ребутнулась, чтобы установить апдейт, если у меня будет новая видеокарта, то это будет амд, и я больше не хочу на винде сидеть, просто бред, неюзабельно. Гит тоже помойка неюзабельная, stash push по умолчанию туда пихает и не staged изменения, и staged, и потом после stash pop они объединённые, спасибо огромное, как же тяжело в гите потерять данные, ага, да вообще не понятно что какие команды делают со стейджем
Да всё, ничего хорошего, я хочу подохнуть, потому что слишком низкий iq + мне испортили жизнь + я тупой даун + я тупой даун, я не знаю, что мне делать, я никак не могу дождаться, когда все сдохнут и я тоже, очень нужно уничтожение всех людей, пожалуйста
во-первых, их не отличить от вызова обычных функций, то есть если ты увидел что-то вроде "do_something()", то, не прочитав весь код (все дефайны) до этого момента, ты не можешь знать, это макрос или вызов функции, и нужно ли его раскрывать
во-вторых, у функциональных макросов сначала полностью раскрываются аргументы и потом они подставляются в функциональный макрос, то есть ты не сможешь просто по очереди всё раскрывать, придётся вперёд смотреть, например, в "a(b(c(d)))" нужно будет сначала раскрыть d, потом c(раскрытое d), в раскрытии которого тоже могут быть макросы, которые придётся раскрыть
И я не знаю, как хранить всё это в процессе раскрытия макросов, я думал, может быть, в связном списке хранить токены, среди которых могут быть нераскрытые макросы, и понемногу их раскрывать, вставляя на место макросов последовательность других, но это вряд ли сработает как минимум из-за того, что в случае с функциональными макросами придётся как-то запоминать, каким образом изначально было разбиение на аргументы, ну типа
> #define first a, b
> #define second c, d
> #define test(a, b, c, d) (a) (b) (c) (d)
>
> test(first, second)
это при раскрытии не должно выдать (a), (b), (c), (d), нужно запомнить, что "a, b" - это первый аргумент у test, а "c, d" - второй. Придётся как-то это учитывать, короче, макросы это не просто search and replace как в текстовых редакторах
И ещё в расте в std нет нормального связного списка, там нет способа вставить в середину за O(1): нельзя разбить связный список на два по позиции курсора, пришлось бы писать свой.
Наверное, придётся делать что-то древовидное и постепенно его раскрывать, типа, если есть такое:
> #define add(a, b) a + b
> #define f3(f, a, b, c) f(f(a, b), c)
> #if f3(add, 1 + 1, 2, 3) == 7
> idk
> #endif
Ну, наверное, читаешь все определения и сохраняешь их в каком-то виде, например
название макроса, названия параметров, определение макроса для function-like макросов:
> (String, Vec<String>, Vec<Token>)
или название макроса + определение для object-like макросов:
> (String, Vec<Token>)
а токены в определении макроса сохраняются так:
> enum Token {
> Obj(String),
> Func(Obj(String), Vec<Vec<Token>>),
> Seq(Vec<Token>),
> Other(...),
> }
И тут Func - это просто что угодно, что выглядит как f(x, y, z), но мы не знаем, это вызов функции или макрос. А Obj - это какой-то идентификатор, за которым нет круглых скобок. И название Func хранится как Obj, потому что оно в теории тоже может раскрыться:
> #define add(a, b) a + b
> #define test(a, b) f(a, b)
> #define f add
> test(1, 2)
Типа, add сохранился бы как (add, [a, b], [Obj(a), +, Obj(b)]) и потом, когда надо будет делать подстановку, просто меняем Obj(a) на аргументы-последовательности-токенов внутри первого аргумента.
Ну, допустим, пришло время развернуть "f3(add, 1 + 1, 2, 3) == 7". Ты сначала парсишь это как Vec<Token>, ничего не раскрывая:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
Потом идёшь и раскрываешь все аргументы у Func, раскрываешь Obj в названиях Func, и просто все Obj макросы тоже раскрываешь. И если попадаются названия макросов у Func, то раскрываешь это всё как function-like макрос:
> [Func(Obj(f3), [Obj(add), Seq([1, +, 1]), 2, 3]), ==, 7]
> [Seq([Func(Obj(add), [Func(Obj(add), [Seq([1, +, 1]), 2]), 3])]), ==, 7]
> [Seq([Func(Obj(add), [Seq([Seq([1, +, 1]), +, 2]), 3])]), ==, 7]
> [Seq([Seq([Seq([Seq([1, +, 1]), +, 2]), +, 3])]), ==, 7]
И, наверное, так придётся утюжить раскрытие каждого макроса до тех пор, пока там не останется нераскрываемых символов, потому что может быть
> #define z 42
> #define y z
> #define x y
> x
Выглядит тупо, но я не знаю, как нормально сделать без этого древовидного бреда и вообще даже так, я не представляю, как это написать более-менее нормально и не совсем длинно
Во Free Pascal макросы (там нет функциональных, но функциональные должны делаться несложной модификацией, заключающейся в том, что на время их непосредственного раскрытия их аргументы тоже считаются специальными макросами; лет через 10 сам сделаю... ... ...) сделаны следующим образом: штука, которая читает токены (на самом деле символы, но, наверное, это естественно делать на уровне токенов, чтобы проще обрабатывать пустые макросы, конкатенации и т. п.), может быть переключена на новый файл, а по его завершении возвращается к предыдущему. Само по себе это реализует инклюды, но и макросы реализованы как псевдо-файлы, на которые сканер переключается и затем возвращается к предыдущему (настоящему файлу или внешнему макросу). То есть мы работаем не со связным списком токенов, в середине которого периодически устраиваем разворачивания, а со стеком файлов и единственным токеном, читаемым в данный момент.
Это позволяет результату разворачивания макроса быть сколь угодно большим, его существование в памяти целиком не требуется. Конечно, в зависимости от того, в какие конструкции он разворачивается и что с ними происходит дальше, это может не помочь, но, во всяком случае, даже тогда препроцессору делает честь, что с нехваткой памяти упал не он.
Кринж https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=64ebd994488a455174ca4d06a34942c4
Мега кринж https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=d4e5b586dbb2f40abf1f7f2df303ed60 Я перестаю понимать зачем вообще жить хочется уже подохнуть поскорее, потому что вообще ничего хорошего не вижу уже, никакого смысла нету и ничего хорошего не будет
Ещё этот непонятный wWinMain, но вроде можно ориентироваться на то, как сделано в вайне https://github.com/wine-mirror/wine/blob/master/dlls/winecrt0/exe_wmain.c
https://godbolt.org/z/7n15qWd3E
Я вообще не знал, что у std::span есть второй шаблонный параметр и по дефолту он максимальный size_t и по дефолту std::span - жирный указатель, но если его размер известен в компайл тайме, то он просто указатель
Ну как бы понятно, что надо просто использовать метод .size(), но просто
Но даже с такими возможностями выстрелить себе в голову мне это больше нравится, чем
чем раст с его трейтами >>668663 и с его const функциями >>687871
- посмотреть строку в буфере
- откусить сколько-то байтов (предполагается, что ты сам знаешь, сколько надо откусить, иначе всё сломается)
- прочитать в буфер больше - это все функции ниже делают автоматически при необходимости, я думал сделать этот шаг явным, но, мне кажется, если, например, тебе надо прочесть следующий символ, но он в буфере есть только наполовину, то ну типо, ты в любом случае захочешь прочитать в буфер больше байтов и тут больше вроде ничего умного в общем случае не придумать, поэтому я просто запихнул это в сами функции, из-за этого они мутируют читалку даже, если это просто peek_char
- посмотреть/откусить следующий символ (просто вообще минимум, что от читалки требуется)
- откусить строку от начала буфера, пока выполняется предикат по символу и его номеру (то есть через неё можно, например, откусить первые несколько символов или откусить до следующего пробела)
- откусить от начала буфера до подстроки-разделителя (например, можно откусить до конца многострочного коммента)
- посмотреть, начинается ли буфер с какой-то строки (например, посмотреть, начался ли многострочный коммент)
И для трёх последних функций есть по два варианта, один кусает более уверенно, чем другой. Типо, например, если предикат нигде не выдал false, то один вариант просто откусит строку полностью, а другой выдаст ошибку. Или, если кусаем до какой-то подстроки-разделителя и в конце есть начальный кусок подстроки-разделителя, но ещё непонятно, это реально она или нет, то один вариант молча кусает до этого непонятного кусочка, надеясь разобраться потом, дочитав его в буфер полностью, а другой выдаст ошибку, что типо буфер слишком маленький или источник, откуда читаем, закончился.
Я думал добавить ещё вариант предиката не по отдельным символам, а по окну из нескольких символов, но, во-первых, я пока что не вижу, где такое могло бы мне пригодиться, а, во-вторых, такая функция слишком сложная, чтобы использовать её в простых ситуациях, но недостаточно сложная, чтобы применять её в сложных ситуациях. Типо, если тебе что-то такое нужно, то, скорее всего, тебе этого не хватит и нужны уже будут полноценные паттерны какие-то или регекспы.
https://play.rust-lang.org/?version=nightly&mode=debug&edition=2021&gist=4ddd00c02b50063955816444b441ee70
Там жсон типо просто для примера использования, мне сейчас лень переписывать свой жсон парсер так, чтобы он не держал полностью строку в памяти, мне вообще для другого, наверное, даже гораздо более простого, оно нужно. И я сейчас смотрю на это и снова получилось полнейшее говно, которым почти невозможно пользоваться, лайк если хочешь нахуй сдохнуть блять
Я знаю про существование BufReader в std раста, но его проблема в том, что у него какой-то не очень интерфейс: там fill_buf читает больше байтов только, если ты буфер полностью законсюмил. То есть нельзя чуть-чуть законсюмить байтов и чуть-чуть дочитать, если что-то не влезло в буфер.
Ещё я чёто, листая код std, понял, что read в трейте Read так-то требует того, чтобы ему давали инициализированную память, куда он будет писать то, что прочёл. Потому что в теории реализацию read ничего не останавливает просто вернуть Ok(42), ничего не записать, и ты потом прочтёшь мусор в буфере, который так и остался незаполненным, и в расте подобные вещи называют unsound, типо, что можно либу каким-то неправильным образом использовать и получить какую-то уязвимость. Но там сделали вот это https://rust-lang.github.io/rfcs/2930-read-buf.html, частично, пока до не доделали.
Там и до этого в рамках std был костыль, чтобы избегать излишних инициализаций буферов https://github.com/rust-lang/rust/pull/81156/files#r766012221, но теперь типо заменили на костыль, который может использовать кто угодно. Но проблема в том, что теперь им, видимо, придётся везде добавлять эти функции, которые принимают https://doc.rust-lang.org/nightly/std/io/struct.BorrowedCursor.html, чтобы явно показать, что сюда можно передавать неинициализированную память. Тут например https://doc.rust-lang.org/stable/std/net/struct.UdpSocket.html#method.recv_from.
Не знаю, правда, действительно ли стоит с этим заморачиваться, это ещё к тому же чисто типичные растопроблемы, какой ужас, я прочитаю мусор. Ну хотя это может вызвать даже UB вроде, но я не понимаю, почему https://rust.godbolt.org/z/Y9rL-5
Очень много unsafe, но я поэтому написал тесты. Единственное нужно с алиасингом осторожнее быть, например, вот это вроде как UB:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> test.as_ptr().add(1),
> test.as_mut_ptr(),
> 2,
> );
> }
А так вроде как нормально, потому что не создаются промежуточные ссылки, когда ты берёшь второй указатель, после того, как ты взял первый указатель. Типо получается, что у тебя есть, например, одновременно константный указатель и мутабельная ссылка. Что-то такое, короче, я не до конца понимаю https://doc.rust-lang.org/stable/std/ptr/macro.addr_of.html:
> use std::ptr;
>
> let mut test: [u8; 3] = [0, 1, 2];
> unsafe {
> ptr::copy(
> ptr::addr_of!(test).cast::<u8>().add(1),
> ptr::addr_of_mut!(test).cast(),
> 2,
> );
> }
Вот можно ли так кастить указатель на слайс я тоже не уверен.
Либо просто только один раз мутабельный указатель взять можно, а не отдельно один мутабельный и один константный.
И это всё компилятор не отлавливает никак. Если у тебя где-то есть указатели, то сам ломай голову с этим, раст сложнее плюсов в разы. Есть miri, но он медленный, не умеет интерпретировать произвольные программы (вроде, например, в FFI он не умеет совсем сейчас) и выдаёт сообщения об ошибках нечитаемые для low iq дебила типа меня.
У меня снова началась эта шиза, потому что мне хуёво блять и я либо сижу и нихуя не делаю, либо занимаюсь хуйнёй, заново переписал конфиг, не глядя на старый-старый, который я даже не использовал в пользу старого более минималистичного. Но получил в итоге примерно то же самое, но на этот раз более-менее разобрался с ленивой загрузкой плагинов, благодаря чему оно хотя бы стартовый экран с меню относительно быстро почти мгновенно открывает, тупо потому что почти ничего не грузит. Корову не я нарисовал, я её украл
Стартовый экран почти бесполезный, там полезное только это перейти в папку с конфигами за одно нажатие кнопки
https://github.com/stevearc/oil.nvim вот это вот прикольно, можно редактировать дерево файлов так же, как текстовые буферы в виме, не надо разбираться со всякими непонятными биндингами
https://github.com/andymass/vim-matchup и это, но только из-за того, что % из дефолтного вима не работает нормально в некоторых ситуациях
https://github.com/debugloop/telescope-undo.nvim и это, но это по сути просто более удобный интерфейс для взаимодействия со встроенной фичей в виме undolist. Типа у меня постоянно проблема в том, что я что-то пишу, потом делаю несколько раз undo, потому что написал кринж, пишу снова, а потом вспоминаю, что я хочу скопировать что-то из текста, который я убрал через undo, и в любом нормальном текстовом редакторе этот текст безвозвратно пропадает
Дерево файлов как дерево и дерево символов не нужны, я обычно просто поиском по названиям по файлам и функциям перемещаюсь
Но я не знаю, стоит ли оно вообще того, есть ли смысл в более сложном автодополнении, чем просто по словам в текущем файле. Я до сегодняшнего сколько-то месяцев использовал максимально минималистичный конфиг неовима, где из плагинов были только vim-surround и цветовая схема, и не то чтобы чувствовал себя сильно обделённым. И то, я думаю, не должно быть сложно написать свой примитивный кеймап для того, чтобы поставить скобки или кавычки вокруг выделения. Типа в виме просто автоматом есть маркеры < и > вокруг последнего выделения, просто на них прыгаешь, вставляешь символы, прыгаешь на изначальную позицию и всё.
С использованием netrw тоже, наверное, можно смириться.
В виме даже греп есть встроенный. Поиск и замену на несколько файлов немного неудобно делать (нужно сначала через vimgrep добавить файлы в quickfix, а потом cdof сделать), но тоже терпимо
https://neovim.io/doc/user/digraph.html#digraphs-use и про это тоже не знал, полезно для меня, потому что я слишком тупой, чтобы запомнить даже несколько юникодовых кодов для часто исопльзуемых символов, которых нет на клаве
Для дебаггинга есть просто gdb, там, оказывается, тупо есть графический режим, где показывается исходный код и для того же раста можно даже настроить сорсмапы для стд. И оно даже на винде почти работает (старая 12 версия работает нормально, а 13 версия и актуальный на сегодня trunk - нет, ну это вот типичный виндовс экспириенс, что ничего не работает). В виме даже есть встроенный плагин для gdb (termdebug), но он как-то не очень работает. Этот получше https://github.com/sakhnik/nvim-gdb и поддерживает lldb ещё
Мне, наверное, надо просто сделать опцию в конфиге, чтобы можно было либо выключить все плагины, либо оставить только минимальный набор (точно без LSP).
После того, как меня заставили пойти в рабство, моя жизнь испортилась окончательно и я хочу нахуй сдохнуть, мне не хочется заниматься этой хуйнёй, я не хочу говнокодить на говноязыке какую-то непонятную хуйню, на которую мне максимально похуй, и мне физически тяжело делать то, что мне не хочется. А в последние несколько недель я и перестал делать, и по сути жду, когда меня пошлют уже нахуй и уволят, потому что так жить невозможно, это буквально рабство, я ничего взамен не получаю, мне нахуй не нужны деньги, точнее, нахуй не нужны такие копейки, какие мне дают, их в жизни моей не скопится в разумные сроки (максимум за год) столько, чтобы хватило на свой дом и жить в нём до конца жизни. А больше нахуй не нужно ничего, ты такие маленькие деньги можешь потратить только на всякую бесполезную хуйню.
Ну разъебал я телефон окончательно об стену, купил новый, но мне телефон так-то не очень-то нужен. Болезни в большинстве случаев сами проходят, зубы, да похуй на зубы: их просто год не чистишь, они обрастают защитой из зубного камня и всё. Что блять на них покупать, шоколадки? да в рот я ебал шоколадки, они все на вкус говно и меня тошнит от них, я не хочу нихуя, я ебал всё и всех в рот, ненавижу. Охуенная трата сил и часов своей жизни в никуда
https://github.com/PowerShell/PowerShell/issues/1908 на это наткнулся, в cmd это просто работало. Я не буду больше пользоваться павершелом, это невозможно. И вингетом тоже, потому что он легко может рандомно заруинить установленную прогу при обновлении. Или установить что-то без нужных зависимостей, но это вообще на винде всегда так, что устанавливаешь что-то, а потом разбираешься, каких dll не хватает. И вскодом, потому что обычно это ещё более худший опыт настройки плагинов, чем в неовиме: куча каких-то жсонов, в которые иногда можно встраивать ${переменные}, нельзя прописать в жсоне просто список плагинов, чтобы вскод сам их установил, нужно обязательно мышкой прокликивать установку.
Микрософт портит мне жизнь. И скриптовые языки тоже, я ненавижу питон, я не понимаю, зачем он существует, ты пробуешь что угодно установить, написанное на нём, и выясняется, что у него есть какие-то платформозависимые зависимости, колёса какие-то, что они то ли компилируются, то ли там бинарники скачиваются, что тебе нужен мейк, сишный компилятор и что в итоге оно всё равно не компилится и выдаёт километр ошибок. Это просто типичный опыт вызова pip install, на винде так точно. На линуксе наверняка иногда тоже, потому что у тебя необязательно установлены все зависимости и естественно pip install не может их подтянуть, это же всего лишь пакетный менеджер для кроссплатформенного языка
Да и другие скриптовые языки, для них у тебя на компе обязательно должен быть установлен интерпретатор и, скорее всего, ещё и пакетный менеджер к нему, потому что миллион зависимостей является данностью для любой проги на скриптовом языке. Нельзя просто запустить прогу, потому что проги никакой нет, у тебя есть только куча бесполезных текстовых файлов
У меня типа просто есть скрипт, который скачивает всякую ерунду, но из-за того, что он написан на жс, я не могу его запустить, мне придётся устанавливать ноду и я так думаю, что ну это слишком сложно, обойдусь
Твой голос буквально АСМР.
А я люблю АСМР.
Не знаю о чем ты там пиздишь, но годно.
То ли мне показалось, что ли у тебя расхождение с тем, что ты пишешь и тем, как ты говоришь. У тебя вполне спокойный нормальный голос, не подавленный какой-то, рассказываешь интересно.
Ты это просто так пишешь, про сдохнуть, типа прикол такой?
Я не могу учиться, я не могу работать, я ненавижу это всё, мои родители эффективно заставили меня пойти на работу, потому что я просто уже не вывозил морально их постоянное нытьё о том, что вот ты какая мразь бросил учиться. И всё, у меня подошла точка, когда меня так сильно выворачивает наизнанку, что я не могу ни на минуту сесть за комп и что-то начать делать, я слишком сильно ебал в рот этот говнокодинг какой-то хуйни, которую я ебал в рот, я ни минуты не хочу больше разбираться в этой куче хуйни
Проблема в том, что мне теперь жить спокойно не дадут, зная что я блять нихуя себе сижу дома давлю кнопки и мне за это платят какие-то обоссанные копейки, и будут ебать мне мозг точно так же, как ебали мне мозг с учёбой, только ещё сильнее, мол, давай иди, иди снова всирай свою жизнь на какую-то очередную долбоёбскую парашу
Я могу уехать от них месяца на 4 максимум, а потом, видимо, лечь на пол, сдохнуть от голода и мумифицироваться, потому что абсолютно все работы доступные человеку с низким айкью - это подобное дегроидное говно, от которого мне хочется залезть на потолок. Либо притворяться, что работаю, блять, подделывать скрины из бансковского приложения
Не могу даже делать минимум спустя рукава, чтобы меня не трогали. И на фоне этого ничем для себя я толком тоже не могу заниматься, из-за ощущения, что вот-вот произойдёт что-то неприятное, из-за того, что в это время мне якобы нужно делать что-то другое, из-за того, что вне зависимости ни от чего будет кто-то, кто будет постоянно трахать мне мозг какой-то хуйнёй для долбоёбов.
У тебя просто нет возможности в течение, например, недели делать только что-то одно, без переключения на другие вещи. А как-то пытаться совмещать - это бесполезно, я пытался, у меня не хватает сил ни физических, ни моральных. Получалось так, что я ничего не успевал, тот треугольник рисовал почти два месяца, например.
Я в итоге сейчас просто целыми днями сижу и ничего не делаю, в состоянии ступора какого-то, я не знаю. Я всегда хотел только одного - чтобы я мог проснуться, осознавая, что никому от меня ничего не надо, что я могу потратить своё время так, как мне вздумается. Но этого просто никогда не будет, потому что, видимо, абсолютное большинство людей всё устраивает, возможно, им даже нравится, когда им нон-стоп ебут мозг.
Если я так и не начну сегодня ничего делать, то возможно меня уволят, потому что я ничего не делаю уже достаточно времени, чтобы это вызвало недовольство. Но проблема в том, что мне как-то всё равно, я хочу, чтобы всё как-нибудь просто закончилось, но мне никто не поможет, просто проблема в том, что меня потом снова погонят в рабство в стойло, либо у меня просто деньги закончатся, если я съеду от них, чтобы они меня не трогали. А откуда брать деньги, не прикладывая никаких усилий, или как жить без потребности в деньгах, при этом пользуясь интернетом и электричеством и не имея своего дома, я не знаю, я слишком тупой и бесполезный для этого
Почему я просто не родился красивой женщиной, всё было бы настолько проще, вот вообще тупо всё, а так это просто бесполезно жить так нет смысла никакого, не на что надеяться, ничего из более-менее вероятного в теории не может произойти, что могло бы исправить моё положение, и я сам ничего сделать не могу, ничего хорошего не будет
Я бы не додумался сам потому что я тупорылый долбоёб
Фликеринг жёсткий
Похуй
блять мне
Какая зп, какой потолок в конторе, скока получают топманагеры, главхуй, скока оборот, какая продукция производится, куда сбывается?
Сори за такие интимные вопросы, но ответь хоть на что-то, раз ты дневниковод.
>Какая зп
Недостаточно большая, чтобы можно было за год рабства ХОТЯ БЫ накопить на покупку своего участка с домом, то есть обоссанные копейки. Как и на большинстве работ: хватает только на то, чтобы покупать всякую потреблядскую парашу, но не на нормальные вещи.
>какая продукция производится, куда сбывается
Это всё не имеет значения. Если у тебя IQ <130, то тебе доступны только бесполезные бессмысленные говноработы, от которых течёт мозг и на которых ты деградируешь, просто впустую всираешь часы своей жизни, свои силы.
И мне похуй на то, что там другие люди считают "полезным" трудом, я, например, в рот ебал центральное водоснабжение. Наверняка дохуя сложно поддерживать в нормальном состоянии всю эту ебаную систему, наверняка нужны какие-то специальные знания и далеко ненулевой интеллект, наверняка большинство людей считают её даже не просто полезной, а жизненно необходимой, но в моих глазах она не нужна, потому что Я НЕ МОЮСЬ БЛЯТЬ.
И что ещё хуже, все эти говноработы порождают потребность только в ещё большем количестве говноработ. Мы построили большой город - теперь нам нужны магазины на каждом углу. Мы нахуярили магазинов на каждом углу - теперь нам нужно развозить в них свежую еду каждый день, теперь нам нужно нанять дохуя людей расставлять товары и разгружать грузовики, теперь нам нужно разрабатывать говнософт для касс самообслуживания, потому что кассиров не хватает. И так далее.
Я ебал всё в рот, мне похуй, ему похуй, похуй похуй похуй
Я скорее всего, съеду от родителей в январе и тогда же стану безРАБотным с 90% вероятностью. И не знаю, что буду делать дальше, не знаю, на сколько месяцев хватит денег. Пытаться снова лезть в говнокодинг за деньги нет никакого желания, не хочу работать, работа - это рабство, мне внутри всё внутри грудной клетки прогрызли крысы
Мельтешение при ресайзе невозможно убрать неважно с двумя скринбуферами или без них в любом случае вроде, не знаю
Единственное, что стоило сделать - это заменить растовый print! на WriteConsoleW, потому что раст похоже делает какую-то буферизацию и непонятно как преобразовывает utf8 строки в utf16 для винды, а я использую юникодовые символы, мне лень разбираться, проще самому сделать, вроде немного лучше (ну точнее в conhost.exe print вообще адекватно не работал, а виндовс терминалу было болееменее нормально с самого начала), но тоже вырвиглазно, короче бесполезно
А я просто что-то подумл зачем нужны все эти графические апи, если есть консоль, в которой можно рисовать квадратики и к тому же ещё и рендеринг текста есть, но не знаю короче
Неплохо. Текстурки порельефнее сделать, (типо "запечь" но без запекания, а вручную всё отрисовав) как в старых играх типо варкрафта.
вот бы поюлозить своим хреном у тебя между сисек
>выделение памяти для структуры через VirtualAlloc
хм, а разве в винде нет malloc? я мало под неё писал, вернее вообще не писал, так что не знаю
>PeekMessage
какое же winapi все таки странное, капетс
даже как-то сказать нечего, графика как была для меня темным лесом, так наверно и останется
В чём проблема? Тебе сколько годиков? Родители нашли заявление на увольнение... ХОСПАДЕ ИСУСИ
Проблема в том, что я не могу больше притворяться, что всё ещё работаю и эти хуесосы теперь снова будут трахать мне мозг тем, чтобы я снова шёл работать каким-нибудь долбоёбом
Стань мужиком и выйди на работу делов-то, все хватит ныть возьми себя в руки !!!
Работа - это рабство и деградация, если у тебя iq < 115, то не существует интересных работ, существует только унылое бессмысленное дерьмо, которым я не хочу заниматься и мне хуёво
Зачем ты привязываешь свой пессимизм к IQ? Боишься чего-то и пытаешься защититься?
Братан ну еду готовить и мусор выносить так-то тоже уныло.
Я не сразу понял, в чём вообще проблема, вот в более понятной для меня форме https://play.rust-lang.org/?version=stable&mode=release&edition=2021&gist=0449b79fa65e5d294f220a4d58dfb95e
Если попробовать на 12 строке вызвать function, то это не скомпилируется, потому что в теле функции попытка вернуть ссылку с более маленьким лайфтаймом, чем 'static, очевидно.
Если попробовать на 12 строке вызвать f1, то тоже не сработает, потому что хоть f1 и указатель на функцию и мы не знаем, что там на самом деле конкретно внутри возвращается с каким лайфтаймом, но из того, что в самой сигнатуре есть параметр типа "&'a &'b ()", следует, что 'b должен пережить 'a. Но у нас 'a = 'static, а 'b - нет, поэтому тоже скомпилируется.
Проблемы начинаются на 9 строке из-за того, что контравариантность типов параметров функции позволяет переход от "&'a &'b" к "&'a &'static". Тут с самой контравариантностью всё в порядке: если в функцию можно передать ссылку с лайфтаймом 'b, то туда тем более можно передать ссылку со 'static лайфтаймом. Но проблема в том, что при этом теряется информация о том, что 'b должен пережить 'a.
Не знаю, почему ещё не поправили это всё, лень читать тред, там непонятно ничего и слишком сложно для понимания
Ещё такой пример есть https://github.com/rust-lang/rust/issues/25860#issuecomment-1680007800 там как будто используется ковариантность типов возвращаемых значений, но я вообще не понимаю этот пример, слишком запутанный
что не работали плагины, зависящие от триситтера (matchup, например), если грузить их лениво,
и что когда открываешь файл напрямую командой через консоль так `nvim file` (а не внутри самого нвима через :e), то почему-то все лениво загружаемые плагины (триситтер, лсп, например) не давали сразу вывести на экран содержимое файла до того, как они все полностью загрузятся. Видимо, это из-за того, что BufReadPost, который триггерит загрузку большинства моих плагинов, триггерится до загрузки UI, из-за чего ждёшь лишние десятки миллисекунд смотря на чёрный экран, пока грузятся плагины.
Только сейчас попробовал посмотреть подробнее код LazyVim (который готовый конфиг, который я сам по себе не использую, только частично смотрел в нём, как настроить некоторые плагины), в общем,
первая проблема решается тем, чтобы предварительно добавить плагин триситтера в runtimepath https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/plugins/treesitter.lua#L11 Чтобы для других плагинов стали по крайней мере видны все скомпилированные парсеры, и этого вроде достаточно, потому что триситтер частично встроен в нвим, но плагин всё равно нужен, чтобы делать через него подсветку кода, но этим другим плагинам, которые используют триситтер, сам плагин не очень нужен? Там вообще какая-то странная двухсторонняя зависимость между ними бывает.
вторая проблема решается тем, чтобы создать кастомный ивент, который при условии триггера BufReadPost триггерится уже только после загрузки UI https://github.com/LazyVim/LazyVim/blob/78e6405f90eeb76fdf8f1a51f9b8a81d2647a698/lua/lazyvim/util/plugin.lua#L114 и грузить большинство плагинов по этому кастомному ивенту, а не по BufReadPost/BufNewFile/BufWritePre.
Из этого выводы, что
дерево зависимостей глубже одного уровня - это зло,
UI, построенный на колбэках/ивентах с непонятно каким порядком выполнения кода - это зло,
скриптовые языки - это зло, потому что люди неизбежно начинают с их помощью надстраивать что-то гигантское, сложное и непонятное,
единственный правильный способ поддержки расширений - это менять исходный код через гит патчи, добавляющие нужный функционал, и самому пересобирать программу?
Или что мне нужно начать пользоваться блокнотом вместо нвима?
Зачем бросил? Хуевит с него?
Я вообще просто хотел понять, что такое машинный эпсилон, потому что когда увидел его случайно в std раста, то подумалось, что а вдруг это то самое, что нужно использовать когда сравниваешь флоаты, но, короче, нет, это вообще дебильное предположение. Он связан с относительной погрешностью, но я так и не понял, какой смысл у того, чтобы взять абсолютную погрешность (например, выраженную в ULP) и поделить её на "настоящее" значение. Видимо, для того, чтобы сделать результат независимым от экспоненты?
Допустим, есть "настоящее" значение 1.0 × 10^{-42} и "вычисленное" значение 1.1 × 10^{-42}. Абсолютная погрешность равна 0.1 × 10^{-42}, что, наверное, ни о чём не говорит, потому что ну типа погрешность выглядит маленькой, но проблема в том, что сами числа тоже маленькие. А относительная погрешность будет равна просто 0.1, наверное, это даёт лучшее представление о точности, не знаю. И если мы работаем с флоатами (β = 10, p = 2), то можно сказать, что ε = 0.05 и оценить количество потенциально неверных знаков с конца через log_β{относительная погрешность / ε}? (p - это размер мантиссы, причём он в том числе включает единицу, которая в IEEE 754 неявная.)
Как я понял, в целом связь машинного эпсилона и относительной погрешности в том, что вот абсолютная погрешность представления флоата максимум равна 1/2 ULP = ((β / 2) · β^{-p}) × β^{e} для какой-то экспоненты e. И эта погрешность верна для всех флоатов в промежутке [β^{e} .. β^{e + 1}) . Но относительная погрешность зависит от "настоящего" вещественного значения, поэтому на этом промежутке она находится где-то в промежутке ((1 / 2) · β^{-p} .. (β / 2) · β^{-p}] - от экспоненты, получается, не зависит. И типо вот как раз верхняя граница этой оценки относительной погрешности определяется как машинный эпсилон. Ну и типо тогда, видимо, имеет смысл измерять погрешность вычислений во флоатах как n × ε, потому что ε - это максимальная точность, которую можно достичь, представляя результат во флоате?
Непонятно, почему-то иногда машинный эпсилон определяется как расстояние от 1.0 до следующего флоата, а иногда как половина от этого расстояния, причём в википедии тоже написано, что это либо то, либо это. Не понимаю.
Ещё один момент, о котором не думал: что во флоатах так-то всякие базовые операции (плюс, минус, умножить, поделить и как минимум вроде ещё квадратный корень) выполняются с максимальной точностью: то есть как если бы флоаты перевели в вещественные числа, сделали вычисления, а потом округлили бы обратно к флоатам. И, как я понял, для этого во внутренней реализации для таких точных вычислений не хватает использования только лишь p цифр мантиссы, нужна хотя бы одна дополнительная цифра (guard digit), чтобы, например, выполнять вычитание двух флоатов с точностью < 2ε (теорема 2 из статьи).
Вроде как эта дополнительная цифра играет роль, когда, например, вычитаешь два числа с разными экспонентами и сдвигаешь мантиссу числа с меньшей экспонентой, чтобы их выровнять.
Допустим, вычисляем 1.01 × 10^{1} - 9.93 × 10^{0}, (β = 10, p = 3)
1.01 × 10^{1} - 0.99 × 10^{1} = 0.02 × 10^{1} = 0.2 × 10^{0}, если не использовать guard digit.
1.010 × 10^{1} - 0.993 × 10^{1} = 0.017 × 10^{1} = 0.17 × 10^{0}, если добавить guard digit.
Но вроде как только одной дополнительной цифры недостаточно для максимальной точности, нужна как минимум ещё вторая дополнительная цифра round digit (видимо, чтобы округление было всегда в правильную сторону, судя по названию? возможно, нужен, потому что когда складываешь или умножаешь нормализованные флоаты, то целая часть может перевалить за 2 цифры?) Sticky bit не знаю, как определяется для произвольного β, в случае с β = 2 вроде как это просто OR всех битов, которые не уместились при сдвиге мантиссы, видимо, чтобы их тоже хотя бы как-то учесть?. Немного более подробно про это я нашёл только тут https://pages.cs.wisc.edu/~markhill/cs354/Fall2008/notes/flpt.apprec.html не знаю, короче.
И, как я понял, этих трёх дополнительных битов должно быть достаточно как для сингловых флоатов, так и для даблов? По крайней мере во всех теоремах про точность вычислений в статье погрешность указывается в машинных эпсилонах, то есть оно не должно зависеть от того, насколько большой сам машинный эпсилон? Вот не знаю, это, наверное, самый непонятный момент для меня.
- Когда вычитаешь друг из друга два близких значения, вычисленных с погрешностью, то получаешь маленькое значение с потенциально очень большой погрешностью (что, наверное, верно не только для флоатов, а в целом в жизни, типо когда измеряешь что-то).
- Даже если финальный результат вычисления умещается во флоат, не факт, что уместятся промежуточные результаты вычислений, из-за чего можно получить вообще неправильный результат (что, наверное, верно не только для флоатов, но и для интов). И ещё, промежуточные результаты могут поместиться во флоат, но быть слишком большими, из-за чего слишком неточными. Чтобы предотвратить это при умножении, можно, например, сделать так (теорема 6): x · y = (x_h + x_l) · (y_h + y_l) = расписать как сумму из чётырёх чисел. В x_h - верхняя половина цифр из мантиссы, в x_l - нижняя. И типо после этого результат не сразу складывать, а попытаться что-нибудь ещё так разложить и сложить члены с одинаковыми экспонентами? Вроде что-то похожее можно сделать, чтобы эмулировать большие инты через маленькие?
- У флоатов нет ассоциативности. И деление не всегда обратимо даже для целых чисел, записанных во флоаты 1002.0F / 100.0F * 100.0F != 1002.0F. Но, что интересно, деление целого числа, записанного во флоате, например, на 10, вроде как почти всегда обратимо умножением на 10 (теорема 7, верно для деления на что угодно вида 2^{i} + 2^{j}, непонятно, правда, в чём смысл и как это хотя бы в теории можно использовать).
- Чем больше флоатовых операций делаешь, тем больше накапливается погрешность, из-за чего, например, вычислять (1 / x)^{n} лучше как 1 / x^{n} (потому что тогда в промежуточных вычислениях степени будет использоваться точный x, а не 1 / x, вычисленный с погрешностью). И эта проблема есть даже с вычислением суммы массива флоатов. Мне это немного ломает мозг с учётом предыдущего утверждения о том, что сумма двух флоатов вычисляется точно, но тут проблема в том, что суммируются не 2, а много флоатов, и на каждом шаге делается округление вместо того, чтобы сложить всё как вещественные числа и потом округлить к флоату. Вроде как есть такой алгоритм, который компенсирует эту погрешность https://en.wikipedia.org/wiki/Kahan_summation_algorithm я не сильно разбирался.
- Флоаты округляются к ближайшему чётному, типо смысл в том, что тогда в 50% случаев в спорной ситуации будет округление вниз, в остальных случаях - вверх. В статье есть вырожденный пример того, что может случиться, если вместо этого округлять всегда вверх (теорема 5), там итеративно прибавляется и вычитается флоат и в итоге результат постепенно смещается, а если округлять к чётным, то остаётся на месте. Интересно, можно ли подобрать такой же вырожденный пример, где бы округление к ближайшему чётному так фейлилось.
И ещё один момент, все эти разговоры о погрешностях имеют смысл только, если входные данные для вычислений - точные. Если они сами по себе вычислены с погрешностью, то не имеет смысла, например, переписывать x^{2} - y^{2} как (x - y) · (x + y), потому что сама разность x - y уже страдает от того, что в статье называется catastrophic cancellation (при условии близости x и y друг к другу), если x и y сами по себе вычислены с погрешностью.
Поэтому, наверное, все вот эти трюки имеют смысл только во всяких библиотечных функциях? В тригонометрических там, например.
Ещё там совсем немного о переводе флоатов в десятичный вид, но не даётся конкретного алгоритма. Только говорится о том, что типа 9 десятичных знаков для сингловых флоатов и 17 для даблов достаточно для того, чтобы перевести флоат в десятичный вид и обратно без потерь. Но это верхняя оценка, на практике может понадобится меньше знаков. Обоснование типо такое, что флоаты вида β = 10, p = 9 на одном и том же промежутке, что флоаты β = 2, p = 24 расположены плотнее, благодаря чему не будет ситуации, когда несколько бинарных флоатов отобразятся в один и тот же десятичный, но при этом может быть наоборот, что два разных десятичных флоата отображаются в один и тот же бинарный - отсюда потенциальная возможность выбрать более короткий вариант десятичного представления, чем 9 знаков.
А как, собственно, переводить флоат в десятичный вид я так особо и не понял. Я пытался читать эту статью https://www.cs.tufts.edu/~nr/cs257/archive/florian-loitsch/printf.pdf но я не осилил, я просто в какой-то момент перестаю понимать, что происходит, я слишком тупой. Ещё такой вариант https://blog.benoitblanchon.fr/lightweight-float-to-string но не знаю, насколько он точный. Там идея в том, чтобы отрубить у флоата экспоненту и потом дробную часть умножить на 10^{9}, привести к инту и привести к десятичному виду. А целая часть после обрубания экспоненты уже должна быть достаточно маленькой, чтобы поместиться в обычный инт. Вроде такая идея.
Тут https://randomascii.wordpress.com/2012/03/08/float-precisionfrom-zero-to-100-digits-2 вроде бы описывается способ точно перевести флоат в десятичный. Там идея в том, чтобы представить флоат как гигантское число с фиксированной точкой (128 бит на целую часть, 149 бит на дробную), чтобы в него записать флоат (по сути достаточно на нужное в соответствии с экспонентой смещение скопировать мантиссу). И потом вроде целую часть итеративно делишь на 10, записывая остатки в целую часть результата. А дробную умножаешь на 10 с переполнением, записывая это переполнение. Типо вроде когда умножаешь в столбик, то обрубаешь всё, что вылезло слева за пределы 149 бит. Я, если честно, ни разу вроде не писал ни деление, ни умножение в столбик.
Ещё у этого же чела в комментариях нашёл про генерацию рандомных флоатов от 0 до 1 https://randomascii.wordpress.com/2012/01/11/tricks-with-the-floating-point-format/#comment-573 В общем, проблема в том, что между 0 и 0.5 флоатов больше, чем между 0.5 и 1 (только лишь между 0.25 и 0.5 их столько же, сколько между 0.5 и 1), из-за чего, если просто взять рандомный u32 и поделить его на u32_max, то на второй половине промежутка некоторые рандомные u32 будут отображаться в одни и те же флоаты, потому что там просто мантиссы не хватает, и это несимметрично с первой половиной промежутка, где флоатов больше. Ну и короче решение просто в том, чтобы обрезать u32 до 23 битов.
Я просто бы, наверное, просто изначально не подумал, что тут есть какая-то проблема, потому что я ебаный даун.
И последнее, вроде как IEEE 754 ничего не говорит о порядке байтов в записи флоатов. По крайней мере в википедии так написано https://en.wikipedia.org/wiki/Endianness#Floating_point Из-за чего в теории порядок байтов у флоатов и интов может отличаться и старший бит инта необязательно соответствует знаковому биту флоата, из-за чего мой abs может в теории не работать. Но, по-моему, всё же на большинстве компов у них порядок байтов совпадает.
А симейк по дефолту линкует весь этот код динамически + использует ucrt через параметр `-Xclang --dependent-lib=msvcrt`. Тут по размеру получается совсем немного больше, чем с -nostdlib. Мне не то чтобы есть дело до того, что экзешник на 100 килобайтов больше или меньше, но типо я просто не понимал, почему у симейка получается меньше размер. Но, с другой стороны, такой экзешник, наверное, не будет работать на винде, где нету ucrt, плюс типичные дебильные ошибки с тем, что не найден vcruntime какой-то версии.
Я, наверное, разучился пользоваться гуглом, но я не понимаю, откуда я вообще должен узнать, что мне надо добавить этот магический параметр и что он означает. Особенно с учётом того, что как будто более очевидное решение передать в линкер `/defaultlib:ucrt.lib` тупо не работает и выдаёт какие-то стрёмные duplicate symbol ошибки.
Если полностью отказываться от линкования с сишной библиотекой на винде, то достаточно просто определить memcpy и memset и поменять main на mainCRTStartup (если subsystem console). Вызовы memset и memcpy компилятор (по крайней мере кланг точно) может сам вставлять в сгенерированный код, поэтому они нужны. Такое есть в том числе в расте, там есть даже отдельная библиотека со всеми подобными функциями https://github.com/rust-lang/compiler-builtins Для x86 ещё какие-то детали с выравниванием стека есть https://nullprogram.com/blog/2023/02/15/#stack-alignment-on-32-bit-x86
Ещё на винде может понадобиться функция chkstk https://stackoverflow.com/questions/8400118/what-is-the-purpose-of-the-chkstk-function но вроде кланг сам что-то делает с троганьем стека и не нужно её определять.
Меня ещё просто бесит симейк и я его использую только из-за того, что он генерирует compile_commands.json (там просто описание как компилировать все юниты), который использует clangd в основном, чтобы знать дефайны, где хедеры лежат и другие параметры компилятора. Может быть, можно его и вручную попробовать генерировать. А так я бы, может быть, просто одной командой все файлы каждый раз бы компилировал.
Но там всего лишь штук 10 ягод на пакет в 100 граммов и у ароматизатора слишком приторный запах какой-то. У меня изначально сложилось неоправданно положительное впечатление от ароматизированных чаёв из-за того, что первым попался очень вкусно пахнущий. А все последующие, что пробовал, были в лучшем случае терпимыми. Может быть, лучше пить без ароматизаторов и купить каких-нибудь сублимированных ягод. Не знаю, будут ли они сами по себе хотя бы запах давать в чае, не пробовал ни разу.
Недостаточно просто после клиппинга нарисовать с нуля линию между клипнутыми точками, нужно сохранить наклон старой линии + инициализировать брезенхама в состояние такое, как будто он сам дошёл до пикселя, с которого начинаешь рисовать. Иначе клипнутая линия не будет совпадать с оригинальной
https://en.wikipedia.org/wiki/Cohen–Sutherland_algorithm это типа самый тупой вариант, вроде можно умнее, но я не смотрел и сам не придумаю потому что я ебаный даун
https://git.musl-libc.org/cgit/musl/tree/src/math/floorf.c избегают того, чтобы просто взять и сделать каст к инту и обратно, вместо этого находят, где запятая и вручную делают -1 для отрицательных нецелых, вручную зануляют биты мантиссы
Я не знаю, как должен выглядеть ui код, пока что бред какой-то получается
Я как-то не задумывался, что можно сделать round просто через целочисленное деление, если просто (делимое + делитель / 2) / делитель, но если учитывать отрицательные числа, то получится слишком громоздко, тогда неинтересно
Из CMAKE_C_FLAGS_DEBUG и CMAKE_C_FLAGS_RELEASE убрать все дефолтные флаги и прописывать все флаги вручную. Для мультиконфиг билдов нужно это https://cmake.org/cmake/help/latest/manual/cmake-generator-expressions.7.html потому что на момент конфигурации ты не знаешь, билдишь релиз или дебаг и не можешь просто сделать if(CMAKE_BUILD_TYPE ...). add_compile_options и add_link_options зачем-то выпиливают дубликаты флагов. Нужно делать, например, add_compile_options("SHELL:-Xlinker ..." "SHELL:-Xlinker ..."), иначе он выпилит второй -Xlinker.
Пытаться настроить симейк - ещё более бесполезное занятие, чем сидеть писать конфиги к текстовому редактору
Ничего не понимаю, что я делаю. Типа совсем, я не понимал, почему mov из памяти в регистр не работает (нету версии mov из 8-байтового immediate адреса и, видимо, нужно либо относительный адрес делать, либо в регистр абсолютный адрес класть).
И что некоторые операции над младшими кусками регистров зануляют верхние, в том числе у xmm. Но только некоторые, mov al, например, остальные байты не трогает. Поэтому, видимо, если функция, возвращает bool, то проверять нужно именно al, а не rax целиком
И что на винде перед вызовом функций нужно на стеке выделить как минимум 32 байта, но я не понял, зачем. И что стек должен быть выровнен на 16 байт перед вызовом функций, но в начале функции он сдвинут на 8 байт из-за того, что call запушил адрес, куда возвращаться
Квадраты рисую не я, и даже нахождение внутри квадрата не я проверяю, это вот это https://www.raylib.com/cheatsheet/cheatsheet.html Виндовое ABI вроде более-менее простое
И прикольная идея с тем, что можно несколько раз применить DDA. Типо, что если вычисляем функцию f(x, y) для последовательных точек, прибавляя постепенно D(x, y) = f(x + 1, y) - f(x, y), то эту D(x, y) можно тоже вычислять так последовательно что-нибудь прибавляя.
Я не знаю, как сделать клиппинг для окружностей. Я нагуглил только это https://theswissbay.ch/pdf/Gentoomen%20Library/Game%20Development/Programming/Graphics%20Gems%203.pdf (IV.3 A fast circle clipping algorithm), но это как будто бред какой-то бессодержательный, арккосинусы ещё зачем-то
Типо просто наивно найти точки пересечения прямоугольника и окружности, наверное, и нарисовать видимые куски. Для нахождения точек пересечения с точностью до пикселя нужен квадратный корень с округлением к ближайшему целому. Тут https://en.wikipedia.org/wiki/Integer_square_root#Algorithm_using_Newton's_method пишут, что для округления вниз метод Ньютона для квадратного корня достаточно остановить в момент, когда |x_{k+1} - x_k| < 1 и вернуть floor(x_{k+1}) как результат.
Для округления до ближайшего целого вроде как достаточно остановиться в момент |x_{k+1} - x_k| < 0.5 и вернуть round(x_{k+1}), но я не понимаю, как это формально доказать. Я не понимаю, как с погрешностью связана эта разность предыдущего и следующего приближений
У меня чувство, что по крайней мере залитые одним цветом круги проще рисовать просто проходясь по всем пикселям внутри квадрата
Но в самом triangle fan в контексте рейлиба смысла мало, потому что DrawTriangleFan на самом деле в любом случае там куда-то внутри себя собирает вершины треугольников, чтобы когда-то потом в одном батче их все нарисовать. И там внутри нигде не используется GL_TRIANGLE_FAN, не делается ничего через рестарт индекс.
Я не ожидал, что в xmm похоже вообще нельзя загружать immediate значения, только из памяти или из других регистров. То есть приходится придумывать названия для каждой константы. И что пользоваться fpu сложнее, чем другими инструкциями: там какой-то свой отдельный стек, в который ты пушишь аргументы, делаешь операции и потом достаёшь результат. И похоже, что доставать/класть аргументы можно только промежуточно положив их в память, нельзя из обычного регистра положить что-то на fpu стек или наоборот перенести из fpu стека в регистр.
И я всё ещё не понимаю, как прочитать в регистр что-то по абсолютному 64-битному адресу, nasm обрезает адрес до 32 бит и sign экстендит эту половину до 64 бит, когда я пишу "mov r, [abs qword label]". При этом как будто бы оно существует "Move r/m64 to r64" https://www.felixcloutier.com/x86/mov но почему у меня ничего не получается. И не получается даже через lea положить в регистр абсолютный адрес, там то же самое.
И адресовать массив, расположенный в data секции, я тоже не понимаю как (ну типа label + регистр умножить на размер элемента), у меня тоже ничего не работает
Не нужно читать по абсолютным 64-битным адресам, доступ к глобальным переменным в x64 почти всегда (когда их меньше 2 Гб; PE EXE в Windows >2 Гб принципиально не поддерживает, и нормально) делается как RIP-relative. Если нужно больше 2 Гб (не нужно, такое нужно динамически выделять и из внешнего файла загружать), есть модели с «абсолютными» адресами: https://wiki.osdev.org/X86-64#Text_Segment_Types, https://eli.thegreenplace.net/2012/01/03/understanding-the-x64-code-models, я не знаю, как они работают, но по логике ты кладёшь адреса в регистр через mov r64, imm64, И — это важно — добавляешь эту инструкцию в relocations, чтобы загрузчик в условиях ASLR и прочего поменял адрес в этой инструкции на настоящий. В “FPC-flavored GNU assembler” это каким-то таким заклинанием делается: https://gitlab.com/freepascal.org/fpc/source/-/blob/139f2dfe84cf07d03e461e50097a426cd88a0797/rtl/x86_64/x86_64.inc#L341 (помещаем адрес переменной fast_large_repmovstosb: boolean в r9 через mov r64, imm64 с добавлением этой инструкции в список релокаций, затем работаем по адресу в r9), в NASM тоже гуглится что-то на тему got / gotpcrel. Короче говоря, лучше не вскрывать эту тему, смысл RIP-relative как раз в том, что фишка напрямую поддерживается набором инструкций, позиционно-независимый код без необходимости вписывать правильные адреса получается автоматически, а 2 (4?) Гб хватит всем.
Чтобы «адресовать массив, расположенный в data-секции», ты сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции, размечтался), и уже потом используешь его как base в base + index × scale.
Ну да, понятно вообщем спасибо, у меня как-то не зарегистрировалось в голове, что абсолютные адреса же ещё будут на каждом запуске разными и непредопределёнными (несмотря на то, что, запуская код в дебаггере, видел, что адреса каждый раз разные)
>сначала помещаешь его адрес в регистр соответствующим способом (RIP-relative — lea reg, [rel arr]; это отдельный способ адресации, несовместимый с base + index × scale в рамках одной и той же инструкции
Ну да, я догадался сделать так и до того, что оно не будет работать с относительными адресами, поэтому снова вспомнил, что у меня не получалось mov использовать с абсолютными в более простом варианте адресации
Если делаешь subsystem windows, то приложение сразу же отсоединяется от консоли и шелл уже показывает промпт для ввода следующей команды, не дожидаясь закрытия гуишного окна. AttachConsole(ATTACH_PARENT_PROCESS) позволяет что-то писать в оторванную консоль из приложения, но это всё ещё конфликтует с шеллом, который рисует следующий промпт, затирает то, что пишет приложение, и обрабатывает инпут из консоли.
Если делаешь subsystem console, то вместе с гуишным окном неизбежно создастся консольное окно, когда запускаешь экзешник из эксплорера. Можно закрыть через FreeConsole, но оно всё равно на мгновение появится. Нужно понять, запустили ли тебя из эксплорера или консоли, чтобы делать FreeConsole только в первом случае. Я видел, люди предлагают смотреть на возвращаемые значения GetConsoleTitle, GetConsoleScreenBufferInfo, AttachConsole(ATTACH_PARENT_PROCESS), но для меня они все не работают вместе с subsystem console. Это https://devblogs.microsoft.com/oldnewthing/20160125-00/?p=92922 вроде работает.
Как это обходят другие люди - делают два экзешника: один - гуишное приложение, второй - консольный враппер. Например, у mpv есть "mpv.com" для консоли - он запускает основное приложение "mpv.exe", передавая информацию о том, что юзер запустил приложение из консоли через переменную среды https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/win32-console-wrapper.c#L95
"mpv.exe" - полностью отдельный экзешник со своей отдельной точкой входа https://github.com/mpv-player/mpv/blob/e42a8d537f575cf61747e9f67c5a9e34f511cb2b/osdep/main-fn-win.c#L60
"mpv.exe" по дефолту запускается в гуишном режиме, но, если задана та переменная среды внутри консольного враппера, то он аттачит консоль родительского процесса "mpv.com" и использует его хэндлы на stdout, stdin, stderr. И тут избегается проблема subsystem windows с тем, что шелл не дожидается закрытия гуишного окна, потому что "mpv.com" висит и ждёт завершения дочернего процесса.
И ещё "mpv.com" почему-то имеет больший приоритет, чем "mpv.exe", когда пишешь "mpv" что в павершелле, что в cmd (алфавитный порядок?) А когда в поиске пишешь mpv, то приоритет у "mpv.exe". То есть оно работает бесшовно, если ты везде пишешь "mpv" без расширения.
Вообще я не знаю, что такое COM, https://devblogs.microsoft.com/oldnewthing/20080324-00/?p=23033 вроде какой-то старый формат экзешников, который просто содержит машинный код с первого же байта. Но в случае с mpv всё же "mpv.com" - это не COM, а PE экзешник с переименованным расширением, но винда умеет такое корректно такое загружать, поэтому всё в порядке, кроме того, что мне очень хочется уже умереть
Типа контекст - структура со всякой ерундой, которую обычно через глобальные переменные делают, например, аллокатор, логгер и прочее такое
Я не придумал, как через такое обобщённое апи сделать так, чтобы динамический массив с линейным аллокатором не тратил впустую память. Добавить функцию реаллок и сделать, чтобы линейный аллокатор мог по возможности расширить последнюю аллокацию, а не выделять новый кусок?
Я хотел бы попробовать написать решение этого https://adventofcode.com/2023/day/1 на саммсебреле, но я слишком тупой и мне страшно. Я так понимаю, когда я буду искать цифры, после сравнения, чтобы достать первую или последнюю цифру в строке, мне нужно будет перевести маску в более удобный вид https://www.felixcloutier.com/x86/pmovmskb и понять, какой по счёту байт мне нужен (через инструкции LZCNT или TZCNT)? Я думал, может быть, есть инструкция, которая бы позволила по маске извлечь один байт из SIMD регистра и положить этот один единственный байт куда-то в память, но не могу найти такое. Самое близкое это https://www.felixcloutier.com/x86/maskmovdqu но это вроде не то, оно сохранит замаскированные байты сохраняя смещения. Shuffle инструкции вроде работают только с immediate, blend - тоже что-то не то, наверное, нет такого, не знаю.
Не хочется жить
А, ссылкиhttps://play.rust-lang.org/?version=stable&mode=debug&edition=&gist=e спойлерземля тебе пухом, кста а в каком моменте он был во втором сезоне? я просто дропнул сезон с первом серии мне не в катила эта тема с рабами bdebafbfaedacaadだ。.
Если ты прочитал вектор по адресу A, что-то насравнивал, и из результата сравнения получил смещение через pmovmskb + bsf/tzcnt (положим i), то для извлечения значения по этому смещению ты перечитываешь его с адреса A + i. :) Я так делал в CompareByte (memcmp), вот здесь https://gitlab.com/freepascal.org/fpc/source/-/blob/b3c1f294ba4b69f2d3bee53730c86af204e456b9/rtl/x86_64/x86_64.inc#L856 перечитываются и вычитаются два байта по смещению, полученному из pmovmskb + bsf.
Теперь попробовал это:
>An aromatic blend of premium Ceylon black tea, raisins and soursop infused with the fruity flavour of white grape wine. With Nuwara Eliya tea, you are offered a fruity taste of grape and soursop with a hint of floral taste. Enjoy every sip.
Он просто невкусный. Меня от него не передёргивает, как от эрл грея после каждого глотка, но он просто пахнет как будто грязной половой тряпкой, а на вкус почти никакой, как будто его и нет почти.
Где-то две недели назад сломал очередные проводные наушники (случайно погнул штекер, я не осилю заменить его: единственный раз, когда пробовал чинить наушники - очень быстро снова их сломал, я слишком тупой для этого). Подумал, может быть, стоит купить беспроводные, короче, теперь кринжовая реальность - что иногда нужно снять наушники, чтобы их зарядить + ощутимая небольшая задержка, когда играешь в игры. А из плюсов от того, что они беспроводные - только, что я теперь не могу сломать провод.
Единственный сценарий, когда они удобнее проводных - когда делаешь что-то на кухне руками, ходишь туда-сюда, и одновременно что-то смотришь на телефоне. Можно телефон в одно место положить, не быть привязанным к нему наушниками и иметь возможность поглядывать на экран.
Про всякие дополнительные вещи, которые обычно пихают в беспроводные наушники, вроде микрофона, шумодава, режима прозрачности, жестов для управления, с моей стороны было бы говорить нечестно с учётом того, что я купил дешёвые наушники. Может быть, в каких-нибудь более дорогих есть, например, волшебный шумодав, который реально все звуки извне блокирует, а не просто давит шипением на барабанные перепонки, как мой китайский кусок мусора хуавей 5i. Но я тут и не рассчитывал ни на что с самого начала.
Короче, беспроводные устройства - это похоже просто очередной гиммик
В общем, если кейсов мало, то if-else.
Если кейсов много, но значения в них последовательные, то генерируется массив из адресов кейсов, куда прыгать, который индексируется значением, по которому делается свитч. Если есть небольшие дыры, то их можно заделать вставкой адреса, куда переходить, если значение не подошло ни под один кейс.
Если кейсов много и между значениями слишком большие дыры, то делается бинарный поиск с захардкоженными всеми возможными ветками и сравнениями. И это может комбинироваться с таблицей адресов для прыжков, если в какой-то ветке бинарного поиска остаётся кусок значений, которые (почти) последовательные внутри этого куска. Вроде бы он ещё умеет видеть кластеры близких друг к другу значений кейсов и делать под каждый из них отдельную таблицу, то есть не просто пополам делить бинарным поиском.
Не знаю, есть ли какой-то предел по количеству кейсов, после которого компиляторы перестают генерировать таблицу прыжков, как будто бы не должно быть, потому что если каждому кейсу соответствует какой-то отдельный уникальный немного осмысленный кусок кода, то эта таблица вроде не должна слишком уж сильно раздуть экзешник по сравнению с вариантом с if-else.
Вроде как кланг в случае со свитчем на 100к кейсов генерирует (очень долго, я не замерял, но минут 5-10) табличку (в коде на 4 картинке видно, что он что-то читает из памяти, там адрес из .rdata секции, и там дальше ниже уже идут разные кейсы почему-то в рандомном порядке). Кстати, сейчас подумал, что может быть, тут можно было бы обойтись и без таблички с учётом того, что размер кода во всех кейсах одинаковый и кейсы идут от 0 до 100к без дырок? Может быть, можно было бы вычислять нужный адрес напрямую, а не индексировать сначала таблицу.
Макросы в виме с навешанными на него плагинами как-то совсем дико медленно работают (я ими генерировал файл со свитчем на много кейсов) и я не уверен, какой конкретно плагин является причиной, было лень разбираться, просто все отключил, когда это делал.
Странно слышать после этого, что вим с плагинами какой-то по-особенному крутой по сравнению с другими редакторами, когда плагины убивают одну из самых прикольных фич вима. Я сомневаюсь даже, что за счёт отсутствия нормального GUI он работает быстрее других редакторов, которые зачастую внутри используют те же самые лсп, что и вим. То есть это уже даже не вим по своей сути, а очередной унылый редактор, у которого единственная отличительная бесполезная особенность - что его внутри терминала можно запустить.
Я какое-то время назад добавил в вим команду, чтобы переключаться между разными шеллами (cmd, pwsh, msys2, wsl) и заметил, что почему-то в как будто рандомные моменты меня начало переключать в wsl-ный шелл. До меня очень не сразу дошло, что я иногда случайно пишу :W вместо :w для сохранения файла, и эта :W выполняет мою кастомную команду :WSL. Потому что виме, если ты пишешь неполное уникальное начало команды, то он её без вопросов выполняет, и так получилось, что единственная команда, начинающаяся на W - это моя кастомная для переключения шелла на wsl-левский.
Короче, я решил это так, что просто назначил на :W тоже сохранение файла