СТРУКТУРЫ - ТВОЯ ГЛАВНАЯ ОШИБКА

[@ExtremeCode]

Братан, хорош, давай подпишись на наш Telegram канал, мы там байки и кулстори травим 🖤 t.me/extremecode

[@ДмитрийТ-к6ч9ш]

Эмбедщики с хардварщиками орут в голосину, кому померещились чудесные массивы без стека и очерди, а так-же без времени доступа

[@Daniel_Zhu_a6f]

если на то пошло, то список, массив, дерево и словарь это тоже несколько интерфейсов (в первую очередь, это функтор и итератор). и вообще, если разобраться, то они внутри из указателей и данных состоят. и тоже могут быть по-разному организованы в памяти (кроме массива).

[@101picofarad]

Стек и очередь - элемент синхронизации разночастотных доменов или разных ядер. Так-то запрета на доступ к середине стека или очереди нет, просто это не целевое использование (долго и дорого). Допустим у нас есть куча источников данных и один обработчик - источники кидают в очередь, а приемник оттуда вынимает по мере сил - очень простая архитектура. Вообще многие структуры такие потому что у них есть аппаратное обеспечение (высокоэффективный хардверный блок).

[@__-ru7or]

Завтра на собесе скажу, что есть структуры и чмоструктуры, надеюсь, что после этого меня сразу возьмут сеньором.

[@shittywizzard5727]

Это будет разговор примерно как между мужиками в интеграции)))

[@artemdme5164]

Интервьюер: "нихуя он умный"

[@user-lv6qm3fj2z]

ну, возьмут или нет - это ещё не известно, а вот пня по жопе получить сходу - прям все шансы есть, да.

[@Дрюха-ш7б]

Надеюсь собес в гугл

[@s_morze]

Давай, расскажешь потом как прошло)

[@ExtremeCode]

Ууууууу, компьютерсаенсеряку порвало. Почитал я, значит, что вы мне тут пишите и у меня разнесло клапан. 1. Свидетели АТД. Чуваки. Я с вами НА ОДНОЙ СТОРОНЕ. Суть очереди/стека как раз в том, что это интерфейсы. Я считаю, что смешивать структуры, которые представляют собой интерфейс и реализацию этого интерфейса, со структурами, которые представляют собой ТОЛЬКО ИНТЕРФЕЙС, офигенно не правильно. Почему? Да потому что реализация интерфейса и и её отсутствие имеет значение (если вы не замечали). Возможно понятия интерфейсов (или контрактов) и реализации надо вводить в книги по структурам сразу. Я даже предложил поправку в определение структур, направленные как раз на то, чтобы закрыть эту брешь. 2. Свидетели "хэштаблица тоже чмоструктура, потому что состоит из других структур". Это не соответствует стандартам консорциума ExtremeCode. Хэштаблица действительно состоит из двух структур. Только вот из-за этого (и хэшфункции) у неё появляются свойства, которые недоступны ни массиву, ни списку. Ну и, очевидно, в отличии от стека с очередью хэштаблица - это не только интерфейс. 3. Свидетели "Получатся, что список не существует, потому что это просто упоротое дерево". Хоть это и не имеет к теме видоса отношения (потому что, как я уже сказал выше, суть в интерфейсах и реализациях), но всё равно отвечу. Это полная дичь, дерево обладает иными свойствами и иными возможностями в зависимости от ситуации. Некоторые вещи, которые возможно сделать на дереве, невозможно сделать на списке. Ну это же очевидно :D Как по мне, если структура настолько обладает иной характеристикой, то её можно считать отдельной. Тут у меня претензии нет. 4. Парни, которые хотят ещё. Консорциум экстримкод решил вас классифицировать как "красавчики".

[@walther514]

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

[@smaramna]

Дядь, на основе списка нельзя делать то что можно делать на основе дерева. Зато наоборот - можно. Так что списки как отдельная структура - не нужны, по твоей же логике. Потому что дерево с одной веткой - это внезапно список. По умным книжкам, структуры разделяют не по принципу применения, а по принципу взаимодействия с информацией. Отсюда выросли списки, стеки и очереди. А ещё есть класная штука, графы называется. Работает по принципу многосвязного списка, к деревьям имеет очень посредственное отношение. Но на графах можно делать такие вещи, которые спискам и не снились. P. S. Про графы упомянул потому что иногда работаю с ними.

[@ВячеславХитёв]

@@smaramna и как же вы храните граф в памяти? Мне всегда казалось, что граф хранят либо как матрицу смежности, либо списком смежности, который хоть и называется списком, но все равно представляет из себя двумерный массив

[@smaramna]

​@@ВячеславХитёв , двумерный массив годится только для маленьких графов. Карту сети аки полная физическая топология, хранить в матрице - тот ещё изврат. Полная карта держится в многосвязном списке с обозначенными четырьмя "углами". Самые необходимые в конкретный момент времени переносятся на разреженную матрицу, которых может быть несколько (кластеры). А работать приходится и с матрицаим и со списками. Вместе это и есть графы, по сути.

[@epromee]

О, второй пункт - камень видимо в мой огород :D Я вот писал, что хэштаблица таки только интерфейс, под которым либо массив, либо массив списков, и мы хз что там. Но если это не по стандарту консорциума ExtremeCode, потому что она, комбинируя массив, список и хэш-функцию, больше не _только интерфейс_ - ну ладно. Пусть она будет не чмоструктура. Как насчёт мапы и сета тогда? Эти ребята уже точно _только интерфейс_ над их хранилищем. upd: ничего не имею против термина "чмоструктура", мне нравится! XD Но всё-таки тогда нужно одно формальное определение, какие структуры чмоструктуры.

[@constantinea.6570]

Давайте будем честными, видос был снят чтобы поролплеить гачи, а не про структуры данных побомбить.

[@nikd2154]

КО подсказывает, что был снят, чтобы рекламу регру не было так скучно смотреть

[@natein-frontend]

Так и есть. И крайне огорчает, что сейчас большинство видео на ютубе вымучивается только для того, чтобы туда интегрировать рекламу.

[@ilya4533]

Чтобы Реакт наконец-то скачать

[@constantinea.6570]

@@ilya4533 я думаю полное скачивание реакта - это будет новогодний спешиал

[@DigitRoach]

Я ради гачи вставки и смотрю

[@krovlood]

Буду честен, как пограмист на микроконтроллерах и чел со специализацией в железе меня порвало. Маладэц, так держать. Ограничения в функционале бывают полезны, а порой необходимы. На уровне железа стэки имеют конкретную реализацию. Когда у тебя всего 16 регистров ( и.с. переменных) стэк реально спасает. Сверху закинем банки памяти (PIC всё ещё их используют) чтоб охуеть конкретно. Чмоструктуры - они чмо только в слоях высокого программирования, а как спустишься на парашу низкого уровня и без них уже очку туго. И ещё, некоторые бинарные деревья можно реализовать на базе массива.

[@FelixX138]

Прикольно =))

[@anatolyvatson2542]

Единственный раз когда я применял понятие стек- 25 лет назад при программирование " Электроника мк 61"

[@user-es5bl2co6k]

если я прочитал какой-то комментарий до конца, то никогда не поленюсь сказать так держать братан давай давай вперёд

[@Molb0rg]

@@anatolyvatson2542 весь ассеблер на стеке, все ваше хайлевел г тоже в асм компилится по итогу, и когда сисечные функции оптимизируешь имеет смысл задумываться

[@МихаилМихайлов-б8т]

Ассемблер привет. Проблема в том, что это пытаются применять на Пайтоне, Джаве, GO и прочем высокоуровневом. А там структуры другие, организация данных другая и прочее, прочее, прочее.

[@АндрійШвайка]

Представляю лицо рекламодателя когда он увидел интеграцию в ролике)))

[@qarbo08]

Зато никто не перематывает 😆

[@regruvideo]

😎

[@NahNahNahnana]

с ним это заранее согласовывается, вероятнее всегo

[@x-neimi4493]

Ну в общем мы возьмем отрывок из знаменитого гей порно. То есть там порно не будет, ну там мем такой в общем. И мы заменим слова так, как будто речь идет не о намеках на интимную близость, а типо про мощные процессоры и расскажем про ваш сервис. Ну в общем так. Вы согласны?

[@gwynbleinn]

3 hundred bucks были уплачены не зря

[@agrun4070]

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

[@darkart6487]

Где это нужно и хватить байтойобить 90% даже не вспомнит за эту фигню

[@agrun4070]

@@darkart6487 если пишешь hello world, то не вспомнишь, если пишешь что-нибудь немного посерьезнее, то оказывается что без структур далеко не уехать

[@HuKuTa944]

@@agrun4070 так я для своего проекта изучил немного теорию графов, узнал про алгоритм Дейкстры и в итоге это помогло реализовать пет-проект, который запустил в небольшой прод. Во как оказаца. Там кстати использовал стэк для подсчета матрицы единичных расстояний. Заморочился я тогда знатно и блин это было чертовски интересно!

[@agrun4070]

@@HuKuTa944 не знаю как ты адаптировал стек для подсчета матрицы, но звучит интересно

[@HuKuTa944]

@@agrun4070 смысл такой. На входе у нас массив нодов (векторов т.е. позиций в 3Д мире), и 2D массив связей. Алгоритм Дейкстры работает так, из каждого нода мы начинаем считать расстояния до всех остальных. И вот тут используется очередь. Добавляем в неё те ноды, которые еще не посетили. В общем там довольно интересный алгоритм, можно загуглить подробности)

[@ДмитрийДодр]

Честно говоря, потраченного времени жаль, пятикратно переваренный кал. Спасибо за творчество, ждём ещё, удачи.

[@epromee]

"Поиск по массиву будет медленнее, чем по бинарному дереву". Вот если поиск не по условию < или >, а по =, то хэш-таблица часто будет ещё быстрее дерева. А хэш-таблицу обычно пилят поверх массива. Вот и получается, что массив не уделывает дерево, а хэш-таблица поверх него - уделывает. Но хэш таблицу на массив можно накинуть по-разному, и по-разному обрататывать коллизии - вот и вопрос - чмоструктура ли хэш-таблица? Получается, да! Но фиг с ней с хэш таблицей. Чмоструктуры ли "map" и "set"? Да! Я же могу под них запихать разные типы деревьев и хэш-таблиц. А разгадка проста, даже Педивикия шарит: " Термин «структура данных» может иметь несколько близких, но тем не менее различных значений: - Абстрактный тип данных; - Реализация какого-либо абстрактного типа данных; "

[@basvalan]

Разве можно хэш таблицу накинуть поверх списка или дерева (и даже если да, то так вообще делают?), а ведь в видео чувак говорит что проблема именно в том что стек можно сделать и на массиве и на списке, на дереве тоже можно но это извращение какое-то.

[@epromee]

@@basvalan Не так. Хэш таблицу можно накинуть поверх массива, но в зависимости от алгоритма разрешения коллизий, там может быть либо массив из списков, либо просто массив (separate chaining, open addressing). Может быть, как-то ещё делают - если да, это не опровергнет, а только усугубит "чмоструктурность" XD Теперь, есть мапа и множество. Вот _их_ можно накинуть на _разные_ деревья или _разные_ хэш таблицы. Причём, ordered только на деревья, а unordered и на деревья, и на хэш-таблицы (если нет строгих ограничений по асимп. сложности) - unordered же не гарантирует беспорядок, он просто говорит, что порядок необязателен. И что там за дерево внутри мап - B-дерево, красно-чёрное или AVL - а откуда мы узнаем, у нас только интерфейс. Помимо дерева в имплементации могут и какой-нить хитровыдуманный LRU кэш присобачить, мы не узнаем. На то они и абстрактные типы данных. Ой, то есть, чмоструктуры. XD

[@ogurezzz]

@@epromee мама, я хочу ворочить ножками микроконтроллеров и никогда не влезать в эти дебри... Мне проще выучить на зубок названия регистров и битов, чем вот это все...

[@agrun4070]

Хорошие примеры и спасибо за разъяснение понятия структур данных. Могу еще добавить, что сбалансированные бинарные деревья тоже можно считать чмоструктурами, так как они пускай и деревья, но реализовываться могут также на основе массива. А про графы вообще молчу

[@epromee]

​@@agrun4070 Спасибо за ответ :) Ну, кстати да, точно - если взять двоичные кучи, то они по сути деревья, но можно выделять их прямо на массиве, как тот же heap sort исполняет. А графы да, всем чмоструктурам чмоструктуры, стэк нервно курит.

[@krakhmalyov]

>Очередь со стеком надо выносить в отдельный подвид Так так все и делают, это "абстрактные типы данных" В структурах мы знаем, как это внутри работает, а у АТД -- только интерфейс, а что там внутри крутится -- неважно

[@krakhmalyov]

Собственно даже в плюсах есть нормальные контейнеры, а есть адаптеры, которые будут работать по-разному в зависимости от того, какой контейнер будешь использовать. Например, std::priority_queue или std::stack.

[@vitaliyvasiliev7854]

Мамкин программист не читатель, мамкин погроммист видеосниматель!

[@ATtiny13a-PU]

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

[@alexperemey6046]

Я так понял вопрос именно в том, "все ли так делают".

[@DadundddaD]

После таких тупых видео можно сразу из рекомендаций каналы убирать.

[@Eugene-Polyakov]

Очередь и стек отдельные структуры во-первых потому что так сложилось исторически, когда в машинах были реальные области данных, которые работали только как стек или очередь и не имели произвольного доступа. С этой точки зрения это реально совсем другая структура, т.к. была реализована на уровне железа. Во-вторых стоит понимать, что реальная структура может быть реализована в железе, в книгах же рассматривают возможные реализации на памяти с произвольным доступом, именно по этому, когда говорят что узел бинарного дерева содержит 2 ссылки это лишь пример реализации в ОЗУ не более и все структуры как раз основываются на интерфейсе доступа к их данным, а не на их реализации и когда говорят про алгоритмическую сложность речь как раз о том как с описанным интерфейсом доступа будут работать те или иные алгоритмы при этом можно вообще все структуры организовать с помощью массива внутри.

[@dmitryopokin8651]

Все структуры и так организованны с помошью массива внутри

[@dunexon3882]

@@dmitryopokin8651 , это ещё с чего бы? Связанный список, к примеру, ты что ли на массиве базируешь?

[@maria-kuznetsova-s]

Очень интересный и грамотный комментарий. Спасибо! Если бы было можно, подписалась бы на ваши комментарии)

[@elena-8363]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще. Твой видос сделал моё утро, оч смеялась :)

[@user_miomit]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@JoeSmith-ll9yn]

непонятный и очень смешной набор фраз если и писать похвалу то по русски а не по армянски

[@МансурДжалалов-б6и]

@@JoeSmith-ll9yn а ты видно не смотришь до конца видео

[@rxrx0255]

@@JoeSmith-ll9yn Выйди.

[@heisserkaiser394]

@@МансурДжалалов-б6и чего токсишь, чувак просто мнение своё высказал

[@Astdaban]

Блин! Ты не поверишь! Я чёт заскучал и решил почитать комменты, и угадай, что произошло... А произошло то, что твой комментарий выпал вторым синхронно с автором. Синхронно, Карл!

[@ИнякинАлександр]

Не знаю как в других языках, но в плюсах никогда не скрывалось, что очередь и стек - это всего лишь адаптеры. Там даже есть явный параметр, через который нужно задавать настоящий контейнер, который будет лежать внутри. Поначитаются всяких ПХП и яваскриптов, а потом жалуются.

[@tzn9597]

В нормальных языках даже нет их

[@alex-cv]

На малых размерах памяти поиск в массиве быстрее, чем в дереве. Потому что кеш и строчное представление памяти. Поэтому листья дерева часто делают из небольших непрерывных кусков памяти, например в 64 байта.

[@темноезастолье]

Это где тебе может понадобится маленький на практике

[@dlearn863]

Я ассоциирую стек и очередь с микропроцессорами, они там вшиты и жизненно необходимы для работы. В программировании это может использоваться для хранения действий пользователя с их последующим откатом (ctrl-z), я их для себя называю "служебными".

[@Astn00]

Автор очевидно вебом занимается, хотя даже в js используется стек, когда функции вызываются например

[@NexoElongur]

Плюсую. Автор, конечно шарит, и его видосы топ. Но структуры данных это не только про программирование. Очередь и стек это больше про железо. ИМХО, автор ниже уровня компилятора не опускался.

[@retywjhdt8290]

@@NexoElongur Тоже самое с константами было, мол они не нужны Хотя в тех же микриках, где борьба за каждый бит памяти, это просто мастхев

[@kodirovsshik]

Очереди в микропроцессорах?

[@NexoElongur]

@@kodirovsshik ну да, очередь микрокоманд, к примеру.

[@diman1ght491]

Братаны, спасибо за гачи, это то, что я ждал от вашего канала последние 14 лет! Лайк

[@oleksandrpetreniuk8854]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.

[@НикитаВасильев-в8б]

Ля, чел ты просто топ. Запили видос по всем классическим паттернам с примерами из игр, про фабрики топ видос, сразу все стало понятно. А то смотришь челов которые снимают курсы и потом еще сидишь и пересматриваешь все что бы понять до конца

[@Solo--way]

Both queue and stack is Abstact data type (ADT), they define interfaces that can be implemented by many ways and other data structures. en.wikipedia.org/wiki/Queue_(abstract_data_type) en.wikipedia.org/wiki/Stack_(abstract_data_type) en.wikipedia.org/wiki/Abstract_data_type

[@arbitertl]

Можно пример имплементации стека на базе бинарного дерева, о которой вы упомянули? :)

[@EvgeniyFadeev]

А какие проблемы? Ну, кроме того что это будет несколько головоломно? Пару дополнительных переменных (начало и конец текущего состояния стека), механизм реализации (типа "добавляем вправо и вниз, вынимаем слева сверху"). И все дела.

[@arbitertl]

@@EvgeniyFadeev ясно, ну, главное, мы все понимаем, что это прикол :) А так, с "дизайном" согласен :)

[@АльбертБадретдинов-у7е]

Массив в питоне динамический, при создании массива компилятор алокейтит определенный минимальный размер памяти, который занимает больше места чем фактически элементы этого массива. Когда массив переполняется, компилятор алокейтит х2 от текущего размера массива, что по памяти, как вы понимаете, не то чтобы очень выгодно по сравнению со stack и queue, т.к. они занимают только тот объем данных, который составляют существующие элементы и не более того. Ну и конечно же не стоит забывать и про производительность, т.к. list.append в питоне занимает O(n), по причине описанной выше, тогда как в queue и stack O(1)

[@bolkonsky2340]

Братан, хорош, давай давай вперед, контент кайф!

[@r.chitector]

по просьбе автора, вот: "Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще." (c)

[@ilfat_akhmerov]

Виталяна смотришь?

[@haxidenti6001]

Автор сам себя накручивает. Позор😔😔

[@ATtiny13a-PU]

@@haxidenti6001, ну это называется либо байт, либо рофел, а вообще ютуб сканит такие сообщения и выкидывает из учёта. Тупо написав 1 ботом 20к сообщений сыт не будешь

[@ДмитрийВолков-н8е]

Не знаю зачем использоваться стек, но очереди я стабильно использую когда делаю систему задач в проектах. Например: у меня есть алгоритм который определяет в какое здание пойдет какой рабочий. Есть классы, вся фигня. НО. Если для здания нет рабочего? А если зданий 2, а рабочий 1? Поэтому создал структуру список. И к ней прикрутил очередь. Мастер класс добавляет приходящие запросы в конец списка, обрабатывает первый элемент. Обработал успешно - выкинул запрос из списка, перешел к следующему. Не успешно - закинул в конце списка, и перешел к следующего. Крайне удобная вещь. Решает миллиард проблем. И без очереди ты хрен решишь эту задачу без миллиарда кода. А то, что структуры могут перекликаться - это классика. Видел список массивов? Или видел дерево списков? Ну вот тоже самое. Как и очередь списка.

[@essentia9]

Первый раз столкнувшись со стеком и очередью, про них было сказано, что это адаптеры, а не отдельные контейнеры. Мне повезло) спасибо SimpleCode😊

[@CHRNBRY]

По факту, один из лучших каналов по шарпу и не только

[@vasilysu]

Блин, зашёл в комментарии альтернативное мнение услышать, а в итоге разгребаю комментарии "Братан хорошо! Давай вперёд!..."

[@АндрейЧудотворов-п2ъ]

Нас в универе учили, что есть массивы, листы и деревья, а очередь со стеком - это частные случаи листа. Так что не всё так плохо :) Ясен пень, что натянуть очередь и стек можно и на массив, но всё же с листом это несколько логичнее. Естественно, я имею в виду связный(двусвязный) лист, а не тот лист, который на основе массива сделан XD

[@stanislavsh6582]

А нас в универе учили, что есть память, в ней лежит что-то и ты ходишь туда-сюда по этой памяти и как-то интерпретируешь это. И все эти типы данных - про то как можно ту или иную функциональность получить интерпретируя данные из этой вот памяти. Все.

[@Dmytro-Tsymbaliuk]

как бы очередь и стек это не про программирование, а про железо, то, что погромисты называют стеком, к реальному стеку не имеет отношение в принципе

[@АндрейЧудотворов-п2ъ]

@@Dmytro-Tsymbaliuk гы... Ну ладно, как скажешь )))

[@ИкромХасанбаев]

Можно поинтересоваться, что за уник?)

[@lebushe]

братан , хорош , давай давай , вперёд , контент в кайф , можно ещё! Ваще красавчик! Можно вот этого почаще

[@ВладимирВоробьев-е6о]

Вот что значит пришла молодежь не державшая в руках ни чего тяжелее компьютерной мышки. Стек - структура поддерживаемая процессором. Там нет никакой надстройки сверху. Очередь тоже поддерживается процессором. Тоже без надстроек. Контент - на двойку на экзамене.

[@kotlinec]

если бы они не поддерживались процессром, нужно было бы их запускать на блютуз колонках или что? какое-то странное у Вас определение

[@Firefox56y]

​​@@kotlinec пример: 7204L12TPG. Тоже самое есть и внутри проца

[@kotlinec]

@@Firefox56y невероятно, но я знаю

[@Firefox56y]

@@kotlinec а что тогда?

[@KocTu4eK]

Братан хорош! Давай-давай вперёд! Контент в кайф! Можно ещё? Вообще красавчик. Можно вот этого вот почаще?

[@MaksymR-y7r]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще РИЛЛ БАЛДЕЖ

[@shufl9dka]

Стек или очередь с поддержкой минимума/максимума/другой функции за О(1) легче понимать через те самые бесполезные стеки, чем через массивы. В этом случае интерфейс хоть и не играет мужыцкой функциональной роли, но тебе становится легче понимать что-то, что пишется на них. Так-то дерево отрезков какое-нибудь тоже можно натянуть на массив в большинстве задач, но убрав дерево отрезков и оставив массив, жизнь не всегда становится проще

[@sergeyz4591]

Ну так то да, списки и очереди, скорее всего, являются подструктурами массива или чего угодно, но не полноценными структурами. Приравнивать их ненужно т.к. это может вводить в заблуждение неокрепшие умы. В любом случае, это удобные подструктуры во множестве случаем. Вот простой пример: читаешь чужой код и видишь там переменную `stack`, а не `arr` и сразу станет проще понимать дальнейший код. То есть массивы -- что-то универсальное, а стеки и очереди разветвление от него. Вот возьмёт тот же самый цикл for со счетчиком и может обнаружить, что у него много аналогов (в зависимости от языка). Для чего они нужны? Потому что в каких-то случаях это удобнее и проще.

[@kadaji_ASC]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще. Пошёл к тимлиду и говорю делай меня сеньором я теперь структуры шарю. Ну он спросил какие. -структуры и чмоструктуры. Лид встал, собрал свои вещи со стола и сказал что это теперь моё место а сам пошёл к большим дядькам просить мне зп как у СЕО.

[@OxiOko]

О! Новое из рубрики "Тайны Истинного Кодера" знание которых избавляет вас от нервного ТИКа

[@danyalutsevich]

Братан хорош давай вперед!! Контент в кайф можно еще? Вообще красавчик!

[@MrRyiiba]

За такую интеграцию - смотря рекламу до конца без перемотки и перехожу по ссылке! Заслужил!)))

[@Ne4ego]

по поводу скорости поиска что-то странное, бинарный поиск есть и в массивах

[@nowifi4u]

Граница между "структурами" и "чмо-структурами" не такая уж и чёрно-белая, то же самое бинарное дерево можно запросто реализовать и через массив, что значительно ускорит некоторые операции, даст непрерывный кусок памяти под данное дерево, быстрый поиск и т.п.

[@JoeSmith-ll9yn]

виндертон - фуфло

[@takiekakmi7532]

Ага, ты только не ляпни такое при людях. Извращенец)

[@seriously1191]

@@takiekakmi7532 Ох уж этот извращенец! На памяти экономит!

[@takiekakmi7532]

@@seriously1191 организовать адекватно работающий кастомный стек на проде - никто не даст. С большей вероятностью - тимлид отправит оптимизировать алгоритмическую составляющую🤷‍♂️ да и просто представь, что такой умник не добавил канарейку, прод наглухо умирает, данные слиты, потери по бабкам, и как итог - увольнение👌

[@hasbeenbefore]

Да но тогда сложность добавления элемента вырастает с logn до n.

[@k..]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.♿

[@dmitriyzinoviev9922]

"Поиск по массиву будет медленнее, чем по бинарному дереву" - Про кеш видимо все забыли, и что есть кейсы, когда быстрее поиск в массиве, чем в бинарном дереве, просто из-за постоянных кеш-мисов в бинарном дереве, в то время как в массиве мы просто пролетаем массив за счет префетча. Массив изображен крайне бесполезной структурой данных в видео =\

[@aleksandertrubin4869]

А ещё массив может быть отсортирован. Причем на отсортирован массиве бинарный поиск скорее всего окажется быстрее чем поиск по бинарному дереву.

[@mega_mango]

Тут прямо полностью согласен. Никогда не понимал, на кой хер они нужны, но думал "для чего-то там используются... Когда нибудь углублюсь". Теперь на 80% уверен, что ошибался

[@maria-kuznetsova-s]

"Не надо мне тут скользить, как функциональщики". 😂😂 Автор ты просто мега крутой и подача огонь! 🔥 Не знаю, насколько ты прав. Сейчас буду читать комменты и разбираться. Но в любом случае помог посмотреть с другой стороны на эту тему. Прошу продолжай делать ролики.

[@shaweles]

[Братан, хорош, давай, давай, вперед, контент, в, кайф, можно, еще, вообще, красавчик]

[@denisulianov9627]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще

[@Валик-ш9ц]

Братан хорош!!! Давай дв вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще

[@vladyslav1768]

Братан, харош, давай давай, вперед!!! Контент в кайф, можно еще? Ваще красавчик!

[@c4llv07e]

"та самая" реклама от extremeCode вышла на новый уровень. Как скоро нам ждать чтение хентайного-манула по запуску сервера на рег ру?

[@maximgorskij6155]

Мегахарош. В программировании не шарю, но темой интересуюсь и благодаря тому, что ты в использовании сложных терминов не сдерживаешься как буд то бы новый язык учу. Мемы кста тоже классные. Красавчик)

[@VladykaVladykov]

Вообще-то, используемый блок памяти может быть расположен в разных местах аллоцированного блока памяти!!!! Значит можно получить выигрыш в производительности!

[@ПетрФедулов-ц1у]

Реально годный видос, получил удовольствие от просмотра и с радостью пофлексил новыми знаниями перед друзьями

[@JusteG01]

Очередь и стек - полезные сущности, зря ты на них набросился) Согласен, что к отдельным структурам данных относить их не корректно - что одно, что второе по своей сути - массивы, только вот не с ограничивающим интерфейсом а завернутые в классы с логикой. Интерфейсами их поведения не добиться, увы. Что же до вопроса: "Зачем себя ограничивать когда есть мозги, прямые руки и здравый смысл" - не согласен в корне. Во первых: Такое ограничение - гарант, что сущность будет использована только теми способами, которые предусмотрел архитектор. Соблюдение этого условия - один из ключевых факторов в написании надёжного, сопровожаемого и расширяемого приложения. Во вторых: Это очень простые и понятные абстракции конкретизирующие принцип работы сущности, а использование абстракций - один из ключевых способов управления сложностью, что в свою очередь является главным императивом разработки програмного обеспечения. Твои нападки на эту истину - звучат как вопли яваскриптера-багодела, ничего сложнее хелоуворда не быдлокодившего)

[@evgenbuiko2021]

Душнила на связи при бинарном поиске по отсортированному массиву это будет равно поиску по дереву Видимо автор изучает программирование по тик току

[@amobius6099]

Молодец, мне уже сто лет примерно, но я угарнул отлично

[@artursword3288]

Эта КОРОБКА даёт ЛОГИКУ поведения.. которая как раз и зачастую нужна для программирования, а СПОСОБ хранения данных или "прохода по данным" это слегка про другое.. очевидные же вещи.. то же ДЕРЕВО это структура с определенной ЛОГИКОЙ поведения, так почему же не имеет право на жизнь СТЕК с ОПРЕДЕЛЕННОЙ ЛОГИКОЙ поведения.. ВСЕ структуры нужны, просто современные программисты скоро вообще НИЧЕМ пользоваться не будут, а тупо в редакторе мышкой накидали и в прод.. возможно если до автора не дошло ЗАЧЕМ нужны стеки и очереди, значит скорее всего он в своей жизни не писал ни чего сложнее сайтика на вордпрессе... других объяснений у меня для вас НЕТ..

[@Rayvenor]

Логика поведения это слишком общее описание. Цикл тоже задаёт логику поведения. Способ хранения это тоже слишком общее описание. Оперативная память, HDD это тоже способ хранения. Стек и очередь задают как возможно пользоваться данными, но не задают как эти данные организованы. Как пользоваться - это интерфейс, организация - это структуры.

[@artursword3288]

@@Rayvenor естественно ОБЩЕЕ, всё в нашем мире можно представить в виде абстракции к абстракции(ну найти более высокий уровень).. так ведь и он же воду льёт замыливая суть ..а что только ЦИКЛ логика тут, а принцип доступа что уже не ЛОГИКА ? ну камон :)))))) я то отчасти согласен и с вами, кроме "Как пользоваться - это интерфейс, организация - это структуры" как раз структура в определенном языке как раз в себя включает И логику поведения И способ хранения.. ибо в разных языках реализация структуры(под капотом) может гулять но не сильно.. если вы измените поведение связного списка до стека, то это уже не будет связный список ввиду ограничений логики поведения, а станет СТЕКОМ... и пусть вас не путает ПОХОЖЕСТЬ... ибо всё по умолчания похоже и в программировании построено на бинарном принципе.. но мы же тогда не "ко ко ко" что типо а зачем структуры, если всё в итоге всё равно похоже на 1 0 1 0 1.. и только ЛОГИКА поведения на более высоком уровне абстракции делает из них их структуры..

[@Rayvenor]

@@artursword3288 Первую часть совершенно не понял. "если вы измените поведение связного списка до стека, то это уже не будет связный список" Тут вы смешиваете разные понятия, я не понимаю как на это ответить. Предлагаю изменить вопрос. Вопрос: Если бинарное дерево использовать как связный список, то это всё ещё бинарное дерево или уже связный список? Ответ: это ошибка проектирования структуры данных. Другой вопрос: Если вы к структуре данных прикрутили интерфейс, то вы получили новую структуру данных или нет? Ответ: нет, структура данных не изменилась, иначе количество структур данных было бы равно количеству возможных интерфейсов, что практически бесконечность. Понятие структуры данных перестало бы что-то означать. Поэтому "как пользоваться" однозначно определяется "как организовано" и эта связка называется структурой данных. Вашими словами логика хранения задаёт логику использования. Если вам нужна другая логика использования - вы пишете коробочку, которая использует конкретную структуру данных, но не получаете новую уникальную структуру данных.

[@artursword3288]

@@Rayvenor 1) вы сами ответили на свой вопрос :))))))) .. как раз это я и имел ввиду, что под свою задачу и ЛОГИКУ и была придумана структура данных с определенным ПОВЕДЕНИЕМ (как она там Хранит данные это уже вторично) и когда проектировщик выбирает модель он размышляет над ЛОГИКОЙ ПОВЕДЕНИЯ (например скорость поиска, скорость вставки, что ему необходимо в данный момент от данного условно хранилища) 2) "Если вы к структуре данных прикрутили интерфейс, то вы получили новую структуру данных или нет?" как раз так и делали, И со временем появились (как на примере с паттернами) устоявшиеся именованные структуры данных с доказанной полезностью, и сейчас когда говорят стек, то все понимают что имеется ввиду структура данных с принципом LIFO ... ведь так и по вашей же логике получается, что ЛЮБАЯ структура по сути имеет свою ЛОГИЧЕСКУЮ КОРОБОЧКУ над хранением... ну разве вы не видите своей же ошибки в дальнейшей логике? да и не получится их миллионы, ибо тут мы имеем ввиду БАЗОВЫЕ структуры, они по сути самодостаточны, а то что получится у вас будет, это просто синтез этих же самых структур, и в дальнейшем можно просто говорить о классификации их от уровня абстракции.. не дурные люди книжки писали... и мне уж точно смешно слышать как "блогер" затирает что "что то ему нужно" а "что то нет".. можете привести пример ДРУГИХ структур, которые по вашему мнению должны войти в "базовые", и которые отличаются только интерфейсом взаимодействия? в итоге вы и получите ТЕ САМЫЕ структуры которые у всех на слуху.. ибо их полезность уже доказана годами использования .. о вот в том что большинство умеет делать КОСТЫЛИ я и так уверен, воротить СВОИ структуры на базисе исходных, и верить, что они ПОЛЕЗНЫ., такое заблуждение скорее из-за плохого знания матчасти .. и это делают молодые разработчики.. проектируя я прежде всего думаю о поведении структуры (которое естественно, и тут вы правы, строится на внутренней реализации, как и скорость), у меня складывается мнение что вы моё "поведении структуры" путаете с ЛОГИКОЙ самой программы/модуля/куска кода.. в "двусвязном списке" же главное ЛОГИКА, туда сюда ходить, а не что он просто хранит данные, если мне не нужно туда сюда ходить я тупо выбирают другую структуру..

[@Rayvenor]

@@artursword3288 "ЛЮБАЯ структура по сути имеет свою ЛОГИЧЕСКУЮ КОРОБОЧКУ над хранением" Разумеется, но есть одно отличие - ЯП не позволяет залезть под свой капот и использовать интерфейс более нижнего уровня. Поэтому отсчёт структуры как неделимой сущности начинается отсюда. По крайней мере мне это кажется логичным. "проектируя я прежде всего думаю о поведении структуры (которое естественно, и тут вы правы, строится на внутренней реализации, как и скорость)" Проектируя свою структуру вы можете предсказать сколько места она будет занимать в памяти, какие операции будут работать быстро, а какие медленно, какие возможности она предоставит, а какие очно - нет. И это всё предсказывается на основе базовой структуры. Если вы узнаете, что некоторая структура была сделана на основе стека, вы сможете предсказать характеристики этой структуры? Мне кажется это сделать будет затруднительно без знания на базе чего был сделан стек.

[@whoareyouqqq]

Знаете, насмотрелся я на разрабов которые не понимают как словари на хешах устроены, и ждут что уложенные в него ключи будут выданы в оригинальном порядке. Или вообще не знают про словари, ищут значения в списках не заморачиваясь сортировками и размером.... Структуры нужны, не обязательно их писать, но понимать зачем они нужны стоит

[@maksymhernets]

Для языков высокого уровня - да. А для языков низкого уровня - нет. Очень имхо)

[@EvgeniyFadeev]

Стек/дек (очередь) - это не структура данных, а способ организации процесса обработки. Если, разумеется, мы не проваливаемся на уровень ассемблера, где стек - это специальная область памяти со специальной поддержкой со стороны процессора и супервизора.

[@dazbjaxnoname7611]

Братан, хорош, давай, давай, вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[@psifunction]

Есть такая вещь как абстрактные типы данных (АТД), где для каждого типа определен набор операций над ним. Словари, множества, те же стеки и очереди А есть структуры данных, которые определяют реализацию АТД (смежные и связные) И стек можно хоть на массиве, хоть на связном списке построить, суть в том чтобы поддерживать операции, определяющие стек и его поведение Автор явно не прав, называя вещи не своими именами

[@EugeneChe-81]

Братан хорош! Давай вперед) Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще?

[@kambar1647]

Можно вот этого почаще. Вообще красавчик! Можно еще? Контент в кайф. Давай вперед!! Братан хорош!!! блин, я другую чмоструктуру применил, простите пацаны

[@igorglushatov1948]

Поиск в массиве при условии отсортированности имеет такую же алгоритмическую сложность, что и поиск в бинарном дереве, однако и проигрывает в таком случае по скорости вставки, удаления и т.п. Я считаю, что упущение этого факта, доказывает вашу несостоятельность и не квалифицированность, как программиста. Приберите за собой ваш кал, пожалуйста. (Это все шутка, мы вас любим❤)

[@WildAntonOk]

Чего? Какой отсортированности? Вы по-моему теплое с мягким путаете. Работа с данными не равна работе с ссылками на ячейки памяти

[@igorglushatov1948]

@@WildAntonOk вы кто?..

[@ВасяКузнецов-з1м]

Братан хорош!!! Давай вперёд!! Контент в кайф! Можно ещё? Вообще красавчик! Можно вот этого почаще?!

[@Alex113234]

Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще

[@alfany6252]

Осталось только рассказать, что ООП и ФП это одно и тоже, просто взгляд с разных сторон и разная expression problem

[@iliaposmac8672]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще :D :D

[@mobistyle7801]

Занимаюсь программированием микроконтроллеров. Стек это крайне полезная штука для обработки сигналов датчиков. Так показания датчиков обрабатываются в правильном порядке, в удобный момент, и без пропусканий. Так что стек идеально подходит для решения узкоспециализированных задач, и придумали его не просто так.

[@SajDre]

структура данных сама по себе - максимально примитивное понятие, определяемая 2 атрибутами: как хранимые значения соотносятся (внутренняя структура), и какие операции можно над этими значениями совершать. Если какой-то из этих атрибутов оценочно-субъективно выделяется особо и применяется часто, удобно дать этой структуре имя, абстрагируясь от внутренней реализации. Стек и очередь могут быть какими угодно по внутренней организации (1 атрибут), но если подмножество операций которые можно совершать над этими структурами соответствуют признаками стека и очереди - это стек и очередь, потому что так удобно ) И дело не в том чтобы повыебываться, стек и очередь просто есть, и постоянно используются и реализуются на разных видах внутренней организации, а дело на самом деле в том что у автора получилось хайпануть чтобы мне скинули это видео ) молодец, контент развлекательный и многих даже заставит задуматься )

[@lurgee1706]

А правда в том, что есть одна структура данных - дерево. Список - частный случай дерева, а массив - частный случай списка. Ну вот так случилось, что одно - вырожденное дерево, а другое - список, в котором все элементы рядом лежат в памяти. А могло не повезти!

[@Виталий-о3т1и]

Лайк за лучшую рекламу 😂 И за годный еонтент, и подачу, конечно же)

[@nickbelorusov7162]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще?!

[@user-Director_Rigel]

Вот-вот, после изучения списков перешёл к очереди и думал, что это такая же структура, а оказалось, что это просто урезанная версия односвязного списка. Нахрена она нужна, так и не понял. 7:35

[@ar0815]

Братан хорош! Давай вперёд! Контент в кайф! Можно ещё? Вообще красавчик! Можно вот этого почаще?

[@ghostsvsghost]

Братан хорош! Давай, давай... вперед! Контент в кайф. Можно вот этого почаще? Вообще красавчик!

[@mr_m_i_x]

Братан хорош!!! Давай вперед!!! Контент кайф!! Можно еще?? Вообще красвчик!! Можно вот это почаще??

[@sluchainik]

Братан, хорош! Давай-давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще?

[@Anunachi]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@ВладимирКовалёв-у1ф]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще

[@hApyTowNlFUchs36]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!

[@thisismineski9785]

Братан хорош!!! Давай, давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!

[@DenVeR-PRO]

Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@ДенисСидоров-щ3щ]

Братан, хорош! Давай-давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще?

[@vladislavpavlov8638]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.)

[@deluxetv8961]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.

[@АлексейСуббота-ц4п]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@ltyline]

Братан хорош! Давай-давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще?

[@AMartin-yt6gn]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@little-endian6843]

Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@kszystopher]

Братан хорош!!! Давай вперед!! Контент кайф. Можно ещё? Вообще красавчик! Можно вот этого почаще.

[@bivashy]

Братан хорош!!! Давай вперёд!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого почаще.

[@rdbstrd1216]

Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@ДанилПрозоров]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@mb19127]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[@НикитаЧубарь-б2ф]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще?

[@Ikrovosos]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик!

[@andrewsixsixsix]

Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@shkolniklolpro]

Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.

[@isglazunov]

Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик!