Vladimir
ну допустим он хочет писать
Vec<EnumAnything>
в начале, и загружать в конце
Vladimir
Зачем тут структура данных? Он же как я понял с ними особо работать не хочет, просто хранить данные между запусками
Αλεχ
не понял вопрос, поэтому отвечу так: память представляет собой массив, которая индексируется 256-битным указателем. Чтобы сохранить объект, я сериализую его в байтовый массив по 32 байта и пихаю по смежным адресам.
Αλεχ
память не выделяется и не освобождается
Αλεχ
https://github.com/orbita-center/pwasm-abstractions/blob/feature/development/pwasm-abstractions/src/lib.rs#L79
Αλεχ
ну так я и делаю
Αλεχ
фишка в том, чтобы не писать менеджер памяти
Αλεχ
я просто резервирую адресное пространство за объектом и все
Berkus
Αλεχ
Αλεχ
я не занимаюсь тем, что ищу блоки и т.п.
Berkus
но ты знаешь что память зарезервирована и в нее нельзя писать другой объект, да?
Berkus
ну окей, давай не будем называть это управлением памятью, а то еще подумают чего плохое
Αλεχ
нет удаления
Vladimir
Αλεχ
Αλεχ
а у меня этого нет
Berkus
Αλεχ
чет ты злой сегодня
Αλεχ
я вот не знаю, как сделать иначе
Αλεχ
никогда такой херней не занимался
Berkus
у тебя в векторе один объект хранится или несколько?
Αλεχ
сколько напушат, столько и хранится
Berkus
у тебя Vec<u8> или там в каждом элементе вектора сразу целый объект?
Αλεχ
второе
Αλεχ
Точнее смотря про что
Αλεχ
низкоуровнево все хранится как Vec<u256>
Αλεχ
мой Array который я пишу хранит Т
Nikita
Тут на днях всплывал Types and Programming Languages Пирса, ни у кого нет файлика? Желательно на оригинале
Berkus
второе
ну то есть твой эррей выступает менеджером памяти для простого вектора типов
Αλεχ
ну вроде того
Berkus
потому что он всяко поддерживает Vec<u256> сторадж плюс high-water mark чтобы знать куда дальше сериализовать = это уже MM
Αλεχ
что за ватермарка яхз
Αλεχ
если ты про правильное размещение объектов без оверлаппинга то да
Berkus
|start--> allocated ---- | ---- freee |
^ high-water mark
Berkus
у тебя простой arena allocator по факту
Nikita
Αλεχ
Αλεχ
я никогда низкоуровневым байтоебством не занимался
Αλεχ
и велосипедю скорее всего
Αλεχ
но я тупо не знаю, как сделать иначе))
Berkus
ну вариантов то тут не много, делай как можешь ) это близко к обычному арена аллокатору
Αλεχ
ну ок
Αλεχ
проблема основная с тем как хэшмапы реализовывать
Αλεχ
но я пока решил просто забить
Αλεχ
и не делать их
Berkus
ну я подозреваю что на тех объемах памяти которые доступны хэшмапы вообще не пригодятся, можно линейным поиском справиться
Roma
но я тупо не знаю, как сделать иначе))
https://github.com/bjut-hz/E-Books/blob/master/program%20language/The%20Garbage%20Collection%20Handbook.pdf в 7ой главе про аллокаторы разные с примерами рассказывают
Αλεχ
Αλεχ
плюс я для нестинга выделяю память по 4 адресных байта
Αλεχ
на 2^32 коллизии возможны
Αλεχ
Αλεχ
бтв кто-нибудь на винде на msvc тулчейне пробовал утечки искать?
Valery
ну а в чем проблема коллизий?
Valery
нормальные хэшмапы от коллизий оборонятся умеют
Αλεχ
Alex
Alex
берут размер оригинала?
Valery
холи щит, а причем тут размер?
Alex
ну хэшмап берет хэш от значения
Alex
верно?
Valery
ну берет
Alex
сохраняешь размер оригинала
Alex
и тогда коллизии в принципе не возможны
Valery
размер оригинала чего?
Alex
от того же от чего хэш составляешь
Valery
давай, с примерами
Valery
есть struct Key(u32);
Valery
у него хэш например вложенный u32
Valery
и есть Key(15)
Valery
то хэш будет 15
Valery
usize например
Valery
что из этого размер?
Roma
Valery
ну хорошо будет Key(u32, u32, u32);
Valery
а хэш будет 1 + 2 + 3