Несколько правок: 16:08 - Как отметил @nikita_x44 - такой способ - это undefined behavior, его нужно заменить на core::slice::from_raw_parts_mut. В следующем видео (Философия unsafe Rust) объясняю, в чём проблема.
Вот что мне бросается в глаза. Программируя на языках типа JS, C# - ты с самого начала и до конца сосредатачиваешься на создании бизнес-логики, и тебя от этого ничего не отвлекает, то на C++, Rust все время приходится бороться с языком и писать всякие велосипеды не связанные с бизнес логикой. На первых - все что нужно для жизни в стандартной библиотеке - асинхронный ввод/вывод, взаимодействие с системой, понятные удобные API, на вторых - постоянно нужны сторонние билиотеки, разношерстные ужасные API, которые хочется обернуть и больше никогда не видеть. Такие ощущения...
Точно знаю, что ты читаешь коменты. 1. Требуется ли ночная сборка rust для использования такого рода кода? 2. Можно ли использовать этот аллокатор (хотя бы теоритически) для аллокации Vec или чего-то подобного? Я точно помню, что в rust есть глобальный аллокатор
Для кода в видео ночная не нужна. Разве что если мы хотим это использовать в const контексте. И да, сделав несколько модификаций (используя стандартный тип Layout вместо ручного рассчёта размера и алайнмента) мы вполне можем реализовать для него трейт Allocator, доступный в ночной версии, только функцию deallocate придётся оставить без реализации.
Согласен, слайс всегда казался мне промежуточным типом, поэтому я неаккуратно обращаюсь с длиной. Надо будет повнимательнее взглянуть на модуль core::slice. Спасибо за замечание!
Обязательно ли в функции alloc вводить дополнительный lifetime 'item? Нельзя ли результату указывать просто 'mem, говоря, что результат не переживёт исходный массив? Тем более, что item потребляется функцией alloc. Или я чего-то не понимаю?
7:50 - Если я правильно понимаю, и не где не путаюсь, то компилятор раста жалуется на то, что мутабельное значение может быть изменено во время сплита, верно? Если так, то эта идея с тем, чтобы "на время" заменить значение self.remaining_mem просто на пустышку, чтобы удовлетворить компилятор, как-то слишком у меня много вопросов вызывает...
Проблема в том, что self.remaining_mem - это поле структуры self. Мы можем производить над ним операции типа .split_at_mut(), пока нам не нужно перезаписать это поле в самой структуре. То есть мы получаем ссылки, зависящие от этого поля, потом само поле изменяем, после чего ссылки инвалидируются, поэтому компилятор это запрещает. В Rust часто приходится делать что-то подобное, трейты Copy и Default помогают в таких ситуациях.
