วีดีโอ

dyn Trait - Zero sized type. Для работы с ним тебе обязательно нужен толстый указатель, но только один. Зачем два в Vec<&dyn Component>? Может так Vec<dyn Component>

Не нужно париться используйте js чистый

Rust = Zayebis!

Спасибо большое, искал, как это работает на всяких указателях и тп. Не находил

Видео было бы более наглядным, если, кроме примеров имплементации, добавить примеры использования в коде. Например, создать круг, прямоугольник и квадрат и посчитать их площади.

14:45 pub unsafe fn new_unchecked - зачем его сделали публичным?

Кажется, это не наследование, а встраивание (embedding), частный случай композиции

Чувак! Ты как раз вовремя! Я только учить начал

Наконец-то нормальное объяснение времени жизни с структурами🤏🤏🤌🤌👍👍👍

Вообще, если правильно помню, то Vec, как раз так получает функционал слайса, формируя его из указателя на первый элемент и длины

Большое спасибо за видео! Однако должен отметить, что на 7:52 наследование прямоугольника от квадрата и наоборот нарушает LSP (Liskov Substitution Principle).

Спасибо за контент по Rust'у :)

С каких это пор Ссылка в C++ является "более безопасной", чем указатель? Синтаксис обязывает всегда прописывать указатель, как указатель, в т.ч. при передаче этого указателя в функцию. Если же функция принимает ссылку, то при передаче какой-то переменной в эту функцию ты можешь не знать об этом, потому что компилятор при этом никак не чихнет. Т.е. передающий переменную считает, что она после работы функции не меняется, однако функция имеет прямой доступ к внешней переменной и меняет ее при необходимости. Офигенно "более безопасно". Со ссылками наоборот нужно работать более аккуратно. Ссылка - это скорее синтаксический сахар, но уж никак не безопасная замена указателей.

Слишком много слов, зачем-то убеждений и попыток чего-то доказать. Лучше бы меньше минут ролик шел чем это

trait

как мне кажется слово НЕПРАВИЛЬНЫЙ в контексте каких то подходов не очень уместно

Наконец-то годнота

Enum dispatch ❤ Можно было рассмотреть работу с dyn в многопоточной среде

Хах, game dev на Rust. Смешно)

базовая идея ооп в сpp и java это возможность создания фреймворка одними людьми и компонент для этого фреймворка другими. в фреймворк case в switch не добавишь. go и rust плохи в этой парадигме. правда на сервере паттерн фреймворк-компоненты не востребованы практически вообще.

Проверка на простоту возможна за O(sqrt(n)), а не за O(n) как на 19:27. for (d = 2; d * d <= n; ++d) { if (n % d == 0) { return kNotPrime; } } return kPrime;

Спасибо за видео :>

Прекрасное видео! Очень хотелось бы поподробнее про ECS)

спасибо за видео! обычно наследование помогает бороться с дублированием кода, а в Rust как будто надо каждый impl писать заново для каждого struct. особенно если используются атрибуты внутренние. можно подробнее как в Rust это решать?

статический диспатч не считается за полиморфизм? something: impl MyTrait по сути компайл тайм полиморфизм же, ты используешь одну функцию, хоть в итоге это всё и раздувает приложение копированием функции под разные типы, или не прав?

Как то тяжело зашло и не факт что правильно понялось.

лайк не глядя

Отличное лого у видео.

я понял кого напоминает мне твой голос и манера разговора - onigiri есть такой крутой блогер)

О! Увидел код, который ни когда не фигурирует в моих рабочих программах! Ожидать переполнения инта в программе после матоперации? Зачем? Просто проверяй входы на соответствие разрешенному диапазону, такому, чтобы операция с числами из диапазона не приводила к переполнению.

Все правильно. Я давно говорил что if (item.y > 0) это полиморфизм.

Классная картинка, но нужен углублëнный rust

С одной стороны хорошо, что автор в конечном счёте предлагает опираться не на туманную терминологию, которую, как видно из комментариев, многие понимают по-разному, что делает её не эффективной в плане передачи идей (независимо от того, чья это вина), а предлагает вместо этого смотреть на суть и на конкретику, анализировать реальный случай / задачу. С другой стороны, есть пара моментов, которые считаю нужным озвучить. Во-первых, утверждение, что enum не влияет на скорость работы - ложное. Если в коллекции будут неким случайным образом чередоваться типы, branch prediction будет постоянно лажать, что в свою очередь будет приводить к потере многих циклов. Кроме того, если для разных типов операция, выполняемая в цикле, потребует разных по объёму данных, то либо они будут храниться по ссылке, что будет приводить к промахам кэша, и опять потере многих циклов, либо элементы в списке будут занимать наибольший размер из задействованных вариантов, что также означает неэффективное использование кэша процессора. На эту тему можно посмотреть ставшее уже классическим th-cam.com/video/rX0ItVEVjHc/w-d-xo.html Во-вторых, пример с выводом на экран адреса - это плохой пример, т.к. вероятность, что адрес с портом действительно должен выводиться так же, как адрес без порта, я бы оценил как маловероятную, скорее всего это ошибка. И хоть можно подобрать правильный пример для иллюстрации, то что плохой пример просочился в видео разбор, на мой взгляд, наглядно иллюстрирует, что нарушения Liskov substitution principle повсеместны, то есть так уж выходит, что подход с абстрактными типами / обобщённым программированием часто генерирует проблемы (тут можно проводить отдельные психологические исследования, что за дефект в нашем человеческом мышлении к этому приводит, а можно просто принять как данность), а значит неплохо бы задуматься - а стоит эта кажущееся "упрощение" кода того, чтобы повышать вероятность ошибок, которые будут накапливаться и создавать скрытые проблемы в проекте по мере его роста, пока в один день не выстрелят в ногу разработчикам?

Капец тут ебалда в комментах разбушевалась))) Так гореть начал, что накатал 5+ разных комментов)))