Кстати, мап и конечный индекс не нужен. Вполне сгодится обычной массив и начальный индекс. Конечный индекс всегда будет длиной массива - 1. Когда элемент убивает из очереди, присваиваем на том индексе null, undefined или удаляем свойство (дело вкуса), чтобы избежать утечек памяти.
Такой вариант реализации тоже возможен, но не хотелось бы иметь постоянно растущий массив. Даже если там и не хранятся данные, в любом случае будет какой-то место занимать (shallow size). + чем больше он становиться, тем менее оптимальными будут все операции. Тоже самое касается и удаления свойства, массивы с «дырками» очень плохо оптимизируются движком, поэтому вариант с присваиванием null выглядит по лучше (Но тогда в очереди нельзя будет null хранить, что может быть и не нужно). С другой стороны, упремся ли мы в эти лимиты когда-то и нужны ли будут эти оптимизации - это уже другой вопрос. Так что вариант валидный, можно и его юзать, it’s up to you! Спасибо за фидбэк!
Проблема такой реализации в том, что если у нас в очереди есть два элемента и в какой-то момент будет происходить удаление и прибавление одного элемента, у нас будет бесконечно расти индексы.
Молодец Айюб! Так держать братан!!!
Оч крутой контент. Не забрасывай ютуб, даже в случае блокировки
Спасибо!
Забрасывать точно не собираюсь)
Спасибо за ролик! Очень помогло!
Рад помочь)
Спасибо большое!
Не за что!
Кстати, мап и конечный индекс не нужен. Вполне сгодится обычной массив и начальный индекс. Конечный индекс всегда будет длиной массива - 1. Когда элемент убивает из очереди, присваиваем на том индексе null, undefined или удаляем свойство (дело вкуса), чтобы избежать утечек памяти.
Такой вариант реализации тоже возможен, но не хотелось бы иметь постоянно растущий массив.
Даже если там и не хранятся данные, в любом случае будет какой-то место занимать (shallow size). + чем больше он становиться, тем менее оптимальными будут все операции.
Тоже самое касается и удаления свойства, массивы с «дырками» очень плохо оптимизируются движком, поэтому вариант с присваиванием null выглядит по лучше (Но тогда в очереди нельзя будет null хранить, что может быть и не нужно).
С другой стороны, упремся ли мы в эти лимиты когда-то и нужны ли будут эти оптимизации - это уже другой вопрос.
Так что вариант валидный, можно и его юзать, it’s up to you!
Спасибо за фидбэк!
Хорош 👍🏻
Спасибо!
Давай еще алгоритмов!
Если быть немного назойливым, то это структура данных, а не алгоритм)
Но идею понял, подумаю, что еще интересного можно снять.
@@ayub_begimkulov тогда так, ещё и алгоритмов 🙃
Здарова! Вот такие видики совсем кайф! По-больше бы ванильного JS)
Привет. Рад что понравилось!
Постораюсь разбовлять таким контентом.
Проблема такой реализации в том, что если у нас в очереди есть два элемента и в какой-то момент будет происходить удаление и прибавление одного элемента, у нас будет бесконечно расти индексы.
Ты это к тому, что индексы могут стать больше, чем Number.MAX_SAFE_INTERGER?
Очень плохо объясняешь, проще код посмотреть, чем твой разбор слушать