В этом видео я напишу свой Аллокатор, который работает с любым массивом байт, который пользователь предоставил по уникальной ссылке. Так же я покажу один из способов применить этот аллокатор в ходе решения задачи с сайта leetcode.
В этом видео я так же немного затрону работу оперативной памяти, адреса, размеры и выравнивание (alignment) структур. Видео так же будет интересно любому, кто интересуется языком Rust, поскольку я показываю много моментов, встречающихся в любых проектах - конфигурация, тесты, модули, трейты.
Видео вдохновлено этой статьёй (Отсюда взята идея подобного аллокатора): matklad.github.io/2022/10/06/...
----------
Поддержать: boosty.to/bitwiseuwu
Код найдёте здесь: github.com/IoaNNUwU/hardcore_...
----------
Это видео может быть интересно любому, кто интересуется системными языками программирования, любит изучать низкоуровневые концепции и работу железа - процессора, оперативной памяти, видеокарты. Если вы знаете или хотите изучить языки C++, Go, Zig - Rust станет отличным дополнением, а возможно даже сможет сместить ваш интерес в свою сторону за счёт таких преимуществ, как безопасность памяти, потокобезопасность, современный API. Rust так же станет прекрасным языком, если вы хотите лишь немного прикоснуться к системному программированию, изучить работу железа, но при этом не оставлять высокоуровневые, простые в использовании языки, такие как Python, Java, JavaScript, Kotlin, Lua.
На этом канале вы найдёте множество видео как на тему системного программирования, так и более общих концепций программирования, таких как ООП, системный дизайн и множество других тем, которые стоят того, чтобы их обсудить.
Наконец то я тебя нашёл. Русскоязычный ютубер что снимает про Rust lang!
ты шо, сума сошел, судя по голосу, ты молодой парень, а шаришь так хорошо, мой тебе респект
11:55. Цикл можно заменить на if temp % align != 0 { temp += align - temp % align; }
Хорошее видео, спасибо за контент
Круто!
Очень интересное видео, спасибо. Я хоть на расте не пишу, но моих сишных знаний хватает, чтобы было интересно)
Не могу разобрать, Гэндальф. Тут что-то на эльфийском.
А самое смешное, что код зависит от стандартной библиотеке в случае когда её нет.
Обязательно ли в функции alloc вводить дополнительный lifetime 'item? Нельзя ли результату указывать просто 'mem, говоря, что результат не переживёт исходный массив? Тем более, что item потребляется функцией alloc. Или я чего-то не понимаю?
Неужели!
Есть в планах осветить тему макросов?
Вполне возможно, тема очень интересная и недавно я снова в неё погружался. Добавлю в список запланированного!
7:50 - Если я правильно понимаю, и не где не путаюсь, то компилятор раста жалуется на то, что мутабельное значение может быть изменено во время сплита, верно? Если так, то эта идея с тем, чтобы "на время" заменить значение self.remaining_mem просто на пустышку, чтобы удовлетворить компилятор, как-то слишком у меня много вопросов вызывает...
Проблема в том, что self.remaining_mem - это поле структуры self. Мы можем производить над ним операции типа .split_at_mut(), пока нам не нужно перезаписать это поле в самой структуре. То есть мы получаем ссылки, зависящие от этого поля, потом само поле изменяем, после чего ссылки инвалидируются, поэтому компилятор это запрещает. В Rust часто приходится делать что-то подобное, трейты Copy и Default помогают в таких ситуациях.
16:08. нельзя создавать даже временные объекты с некорректным инваниантом. в данном случае, нужно использовать `core::slice::from_raw_parts_mut`.
Согласен, слайс всегда казался мне промежуточным типом, поэтому я неаккуратно обращаюсь с длиной. Надо будет повнимательнее взглянуть на модуль core::slice. Спасибо за замечание!
Ахренительный код с сотней уб, падениями на каждый чих и миллионом асейфов. Ну и, конечно же, как обычно кода ничего нет.