Anonymous 03/12/2021 (Fri) 09:17:27 No.9602 del
(65.30 KB 711x968 vector.png)
Писать Иколайси сложно, у меня возникают баги то тут, то там, а я затыкаю их костылями.
Пока не развивал сам Иколайси в -> Иколайси[Лайси], но делаю библиотеку mem.
А в ней планирую очень простой сабмодуль vector, состоящий всего из одного дженерика и штук 15 темплейтов. Еле исправил баги, из-за которых темплейты не парсились. Представляете, в правиле парсинга nestedanyth было записано:
nestedanyth = dapa.forward()

nestedanyth << ((dplit['lrbracket'] + dapa.anything([dplit['rrbracket']],[string,nestedanyth])) | \
(dplit['lqbracket'] + dapa.anything([dplit['rqbracket']],[string,nestedanyth])) | \
(dplit['lcbracket'] + dapa.anything([dplit['rcbracket']],[string,nestedanyth])) | \
(dplit['ltbracket'] + dapa.anything([dplit['rtbracket']],[string,nestedanyth])))

Тут 2 ошибки. Во-первых вложенность при помощи < и > не должна быть, ведь эти символы используются в операторах сравнения. Во-вторых, я забыл, что dapapy.anything после парсинга не включает в себя токен, который заканчивает dapapy.anything, соответсвенно надо было в каждое миниправило добавить + dplit['rXbracket'].
Кстати, насчёт парсинга, я недавно понял, а ведь же современные компиляторы выдают сразу 10, 20, 30 и больше ошибок насчёт кода. Чтобы это сделать, в будущем надо будет перевести парсинг безпроцессинговой части Лайси на парсинг не символов (чарактеров), а токенов. Тогда можно будет сделать отдельные правила для написания инструкций (которые оканчиваются на ;) и потом только проверять правильность их написания, чтобы писать, какие переменные недекларированы и всё такое.

Ещё я подумал о том, что в библиотеку mem надо будет сделать такую хорошую структуру, ух. Я её незвание не придумал, но может будет называться linked. Суть её в том, что есть объект в куче и на него могут ссылаться N указателей и ведётся их учёт. Если удалить один из указателей, то он просто вычтется из структуры учёта, а когда указателей останется 0, то и сам объект удалится.
Что-то подобное linked используется у меня в графическом движке и ГУИ-библиотеке, там один и тот же виджет/меш может отрисовываться в разных местах благодаря этому. А хорошо бы, чтоб можно было не только меш перелинковывать, но и материалы, текстуры, анимации и всё такое.
Ещё подумываю о том, чтобы в библиотеке mem была такая структура как chunk. Это элемент некоторой размерности, некоторого измерения, который может иметь смежные чанки и у каждого одинаковое кол-во внутренних элементов. Вот майнкрафтовские чанки подходят под такой критерий или ещё какие. Но я не уверен в полезности такого отдельного абстрактного элемента, так как, а что если надо сделать чанки шестиугольными или вообще бесформенными и смежность будет определяться по-другому, незнаю, можно ли это нормально реализовать. И что если будет гораздо удобнее использовать обычные октодеревья или N-деревья, это, конечно же, совершенно другая структура данных, но...
А в библиотеку math надо будет сделать сабмодуль image для компьютерного зрения и обработки изображений и других тензоров N-ной размерности. Ну типа фильтр применить, заресмплить, задетектить края или углы, оптический поток и всё такое.