СТРУКТУРЫ - ТВОЯ ГЛАВНАЯ ОШИБКА
ฝัง
- เผยแพร่เมื่อ 15 ธ.ค. 2021
- Хостинг-провайдер и регистратор доменов РЕГ.РУ: go.reg.ru/ExtremeCode
Разбираемся с структурами обработки данных и выясняем что с ними не так
Подпишись на наш Telegram Канал 🖤 t.me/extremecode
_____________________________________________________________
Лицензия Creative Commons Attribution 4.0 на использование трека Hyperfun (исполнитель: Kevin MacLeod): creativecommons.org/licenses/...
Источник: incompetech.com/music/royalty-...
Исполнитель: incompetech.com/ - วิทยาศาสตร์และเทคโนโลยี
Братан, хорош, давай подпишись на наш Telegram канал, мы там байки и кулстори травим
🖤 t.me/extremecode
Эмбедщики с хардварщиками орут в голосину, кому померещились чудесные массивы без стека и очерди, а так-же без времени доступа
если на то пошло, то список, массив, дерево и словарь это тоже несколько интерфейсов (в первую очередь, это функтор и итератор). и вообще, если разобраться, то они внутри из указателей и данных состоят. и тоже могут быть по-разному организованы в памяти (кроме массива).
Стек и очередь - элемент синхронизации разночастотных доменов или разных ядер. Так-то запрета на доступ к середине стека или очереди нет, просто это не целевое использование (долго и дорого).
Допустим у нас есть куча источников данных и один обработчик - источники кидают в очередь, а приемник оттуда вынимает по мере сил - очень простая архитектура.
Вообще многие структуры такие потому что у них есть аппаратное обеспечение (высокоэффективный хардверный блок).
Завтра на собесе скажу, что есть структуры и чмоструктуры, надеюсь, что после этого меня сразу возьмут сеньором.
Это будет разговор примерно как между мужиками в интеграции)))
Интервьюер: "нихуя он умный"
ну, возьмут или нет - это ещё не известно, а вот пня по жопе получить сходу - прям все шансы есть, да.
Надеюсь собес в гугл
Давай, расскажешь потом как прошло)
Давайте будем честными, видос был снят чтобы поролплеить гачи, а не про структуры данных побомбить.
КО подсказывает, что был снят, чтобы рекламу регру не было так скучно смотреть
Так и есть. И крайне огорчает, что сейчас большинство видео на ютубе вымучивается только для того, чтобы туда интегрировать рекламу.
Чтобы Реакт наконец-то скачать
@@ilya4533 я думаю полное скачивание реакта - это будет новогодний спешиал
Я ради гачи вставки и смотрю
>Очередь со стеком надо выносить в отдельный подвид
Так так все и делают, это "абстрактные типы данных"
В структурах мы знаем, как это внутри работает, а у АТД -- только интерфейс, а что там внутри крутится -- неважно
Собственно даже в плюсах есть нормальные контейнеры, а есть адаптеры, которые будут работать по-разному в зависимости от того, какой контейнер будешь использовать. Например, std::priority_queue или std::stack.
Мамкин программист не читатель, мамкин погроммист видеосниматель!
в принципе ты прав. А то по такой логике можно сказать что и дерево можно построить массивом, или через стек, который работает на связном по его словам списке нормально... ну вообщем
Я так понял вопрос именно в том, "все ли так делают".
Представляю лицо рекламодателя когда он увидел интеграцию в ролике)))
Зато никто не перематывает 😆
😎
с ним это заранее согласовывается, вероятнее всегo
Ну в общем мы возьмем отрывок из знаменитого гей порно. То есть там порно не будет, ну там мем такой в общем. И мы заменим слова так, как будто речь идет не о намеках на интимную близость, а типо про мощные процессоры и расскажем про ваш сервис. Ну в общем так. Вы согласны?
3 hundred bucks были уплачены не зря
Честно говоря, потраченного времени жаль, пятикратно переваренный кал. Спасибо за творчество, ждём ещё, удачи.
Буду честен, как пограмист на микроконтроллерах и чел со специализацией в железе меня порвало.
Маладэц, так держать.
Ограничения в функционале бывают полезны, а порой необходимы. На уровне железа стэки имеют конкретную реализацию. Когда у тебя всего 16 регистров ( и.с. переменных) стэк реально спасает. Сверху закинем банки памяти (PIC всё ещё их используют) чтоб охуеть конкретно. Чмоструктуры - они чмо только в слоях высокого программирования, а как спустишься на парашу низкого уровня и без них уже очку туго.
И ещё, некоторые бинарные деревья можно реализовать на базе массива.
Прикольно =))
Единственный раз когда я применял понятие стек- 25 лет назад при программирование " Электроника мк 61"
если я прочитал какой-то комментарий до конца, то никогда не поленюсь сказать так держать братан давай давай вперёд
@@anatolyvatson2542 весь ассеблер на стеке, все ваше хайлевел г тоже в асм компилится по итогу, и когда сисечные функции оптимизируешь имеет смысл задумываться
Ассемблер привет. Проблема в том, что это пытаются применять на Пайтоне, Джаве, GO и прочем высокоуровневом. А там структуры другие, организация данных другая и прочее, прочее, прочее.
Ууууууу, компьютерсаенсеряку порвало. Почитал я, значит, что вы мне тут пишите и у меня разнесло клапан.
1. Свидетели АТД. Чуваки. Я с вами НА ОДНОЙ СТОРОНЕ. Суть очереди/стека как раз в том, что это интерфейсы. Я считаю, что смешивать структуры, которые представляют собой интерфейс и реализацию этого интерфейса, со структурами, которые представляют собой ТОЛЬКО ИНТЕРФЕЙС, офигенно не правильно. Почему? Да потому что реализация интерфейса и и её отсутствие имеет значение (если вы не замечали). Возможно понятия интерфейсов (или контрактов) и реализации надо вводить в книги по структурам сразу. Я даже предложил поправку в определение структур, направленные как раз на то, чтобы закрыть эту брешь.
2. Свидетели "хэштаблица тоже чмоструктура, потому что состоит из других структур". Это не соответствует стандартам консорциума ExtremeCode. Хэштаблица действительно состоит из двух структур. Только вот из-за этого (и хэшфункции) у неё появляются свойства, которые недоступны ни массиву, ни списку. Ну и, очевидно, в отличии от стека с очередью хэштаблица - это не только интерфейс.
3. Свидетели "Получатся, что список не существует, потому что это просто упоротое дерево". Хоть это и не имеет к теме видоса отношения (потому что, как я уже сказал выше, суть в интерфейсах и реализациях), но всё равно отвечу. Это полная дичь, дерево обладает иными свойствами и иными возможностями в зависимости от ситуации. Некоторые вещи, которые возможно сделать на дереве, невозможно сделать на списке. Ну это же очевидно :D Как по мне, если структура настолько обладает иной характеристикой, то её можно считать отдельной. Тут у меня претензии нет.
4. Парни, которые хотят ещё. Консорциум экстримкод решил вас классифицировать как "красавчики".
На сколько я знаю, и дерево и список могут быть реализованы с помощью массива, получается, что разделение структур по интерфейсу и реализации не совсем некорректно.
Дядь, на основе списка нельзя делать то что можно делать на основе дерева. Зато наоборот - можно. Так что списки как отдельная структура - не нужны, по твоей же логике. Потому что дерево с одной веткой - это внезапно список.
По умным книжкам, структуры разделяют не по принципу применения, а по принципу взаимодействия с информацией. Отсюда выросли списки, стеки и очереди.
А ещё есть класная штука, графы называется. Работает по принципу многосвязного списка, к деревьям имеет очень посредственное отношение. Но на графах можно делать такие вещи, которые спискам и не снились.
P. S. Про графы упомянул потому что иногда работаю с ними.
@@smaramna и как же вы храните граф в памяти? Мне всегда казалось, что граф хранят либо как матрицу смежности, либо списком смежности, который хоть и называется списком, но все равно представляет из себя двумерный массив
@@user-px9ch4fl6z , двумерный массив годится только для маленьких графов.
Карту сети аки полная физическая топология, хранить в матрице - тот ещё изврат.
Полная карта держится в многосвязном списке с обозначенными четырьмя "углами". Самые необходимые в конкретный момент времени переносятся на разреженную матрицу, которых может быть несколько (кластеры). А работать приходится и с матрицаим и со списками. Вместе это и есть графы, по сути.
О, второй пункт - камень видимо в мой огород :D Я вот писал, что хэштаблица таки только интерфейс, под которым либо массив, либо массив списков, и мы хз что там. Но если это не по стандарту консорциума ExtremeCode, потому что она, комбинируя массив, список и хэш-функцию, больше не _только интерфейс_ - ну ладно. Пусть она будет не чмоструктура. Как насчёт мапы и сета тогда? Эти ребята уже точно _только интерфейс_ над их хранилищем.
upd: ничего не имею против термина "чмоструктура", мне нравится! XD Но всё-таки тогда нужно одно формальное определение, какие структуры чмоструктуры.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
непонятный и очень смешной набор фраз
если и писать похвалу то по русски а не по армянски
@@JoeSmith-ll9yn а ты видно не смотришь до конца видео
@@JoeSmith-ll9yn Выйди.
@@user-gv1cq4jn1g чего токсишь, чувак просто мнение своё высказал
Блин! Ты не поверишь! Я чёт заскучал и решил почитать комменты, и угадай, что произошло... А произошло то, что твой комментарий выпал вторым синхронно с автором. Синхронно, Карл!
Не знаю как в других языках, но в плюсах никогда не скрывалось, что очередь и стек - это всего лишь адаптеры. Там даже есть явный параметр, через который нужно задавать настоящий контейнер, который будет лежать внутри. Поначитаются всяких ПХП и яваскриптов, а потом жалуются.
Стек и очередь - абстракции, а массив или список - варианты реализации этих абстракций. С таким же успехом можно сказать, что графы - это тоже чмосктруктура, так как они могут быть одинаково легко основаны как на массивах(матрица смежности), так и на списках(списки смехности), а при определенной доле извращения даже на деревьях(хранить массив или список ссылок в каждом узле). Тем не менее, графы являются одной из наиважнейших структур данных, а реализация уже подбирается под задачи. Со стеком и очередью аналогично
Где это нужно и хватить байтойобить 90% даже не вспомнит за эту фигню
@@darkart6487 если пишешь hello world, то не вспомнишь, если пишешь что-нибудь немного посерьезнее, то оказывается что без структур далеко не уехать
@@agrun4070 так я для своего проекта изучил немного теорию графов, узнал про алгоритм Дейкстры и в итоге это помогло реализовать пет-проект, который запустил в небольшой прод. Во как оказаца. Там кстати использовал стэк для подсчета матрицы единичных расстояний. Заморочился я тогда знатно и блин это было чертовски интересно!
@@HuKuTa944 не знаю как ты адаптировал стек для подсчета матрицы, но звучит интересно
@@agrun4070 смысл такой. На входе у нас массив нодов (векторов т.е. позиций в 3Д мире), и 2D массив связей. Алгоритм Дейкстры работает так, из каждого нода мы начинаем считать расстояния до всех остальных. И вот тут используется очередь. Добавляем в неё те ноды, которые еще не посетили. В общем там довольно интересный алгоритм, можно загуглить подробности)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Твой видос сделал моё утро, оч смеялась :)
Братан, хорош! Давай-давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще?
Очередь и стек отдельные структуры во-первых потому что так сложилось исторически, когда в машинах были реальные области данных, которые работали только как стек или очередь и не имели произвольного доступа. С этой точки зрения это реально совсем другая структура, т.к. была реализована на уровне железа. Во-вторых стоит понимать, что реальная структура может быть реализована в железе, в книгах же рассматривают возможные реализации на памяти с произвольным доступом, именно по этому, когда говорят что узел бинарного дерева содержит 2 ссылки это лишь пример реализации в ОЗУ не более и все структуры как раз основываются на интерфейсе доступа к их данным, а не на их реализации и когда говорят про алгоритмическую сложность речь как раз о том как с описанным интерфейсом доступа будут работать те или иные алгоритмы при этом можно вообще все структуры организовать с помощью массива внутри.
Все структуры и так организованны с помошью массива внутри
@@dmitryopokin8651 , это ещё с чего бы? Связанный список, к примеру, ты что ли на массиве базируешь?
Очень интересный и грамотный комментарий. Спасибо! Если бы было можно, подписалась бы на ваши комментарии)
"Поиск по массиву будет медленнее, чем по бинарному дереву". Вот если поиск не по условию < или >, а по =, то хэш-таблица часто будет ещё быстрее дерева. А хэш-таблицу обычно пилят поверх массива. Вот и получается, что массив не уделывает дерево, а хэш-таблица поверх него - уделывает. Но хэш таблицу на массив можно накинуть по-разному, и по-разному обрататывать коллизии - вот и вопрос - чмоструктура ли хэш-таблица? Получается, да!
Но фиг с ней с хэш таблицей. Чмоструктуры ли "map" и "set"? Да! Я же могу под них запихать разные типы деревьев и хэш-таблиц.
А разгадка проста, даже Педивикия шарит:
" Термин «структура данных» может иметь несколько близких, но тем не менее различных значений:
- Абстрактный тип данных;
- Реализация какого-либо абстрактного типа данных; "
Разве можно хэш таблицу накинуть поверх списка или дерева (и даже если да, то так вообще делают?), а ведь в видео чувак говорит что проблема именно в том что стек можно сделать и на массиве и на списке, на дереве тоже можно но это извращение какое-то.
@@basvalan Не так. Хэш таблицу можно накинуть поверх массива, но в зависимости от алгоритма разрешения коллизий, там может быть либо массив из списков, либо просто массив (separate chaining, open addressing). Может быть, как-то ещё делают - если да, это не опровергнет, а только усугубит "чмоструктурность" XD
Теперь, есть мапа и множество. Вот _их_ можно накинуть на _разные_ деревья или _разные_ хэш таблицы. Причём, ordered только на деревья, а unordered и на деревья, и на хэш-таблицы (если нет строгих ограничений по асимп. сложности) - unordered же не гарантирует беспорядок, он просто говорит, что порядок необязателен. И что там за дерево внутри мап - B-дерево, красно-чёрное или AVL - а откуда мы узнаем, у нас только интерфейс. Помимо дерева в имплементации могут и какой-нить хитровыдуманный LRU кэш присобачить, мы не узнаем. На то они и абстрактные типы данных. Ой, то есть, чмоструктуры. XD
@@epromee мама, я хочу ворочить ножками микроконтроллеров и никогда не влезать в эти дебри... Мне проще выучить на зубок названия регистров и битов, чем вот это все...
Хорошие примеры и спасибо за разъяснение понятия структур данных. Могу еще добавить, что сбалансированные бинарные деревья тоже можно считать чмоструктурами, так как они пускай и деревья, но реализовываться могут также на основе массива. А про графы вообще молчу
@@agrun4070 Спасибо за ответ :) Ну, кстати да, точно - если взять двоичные кучи, то они по сути деревья, но можно выделять их прямо на массиве, как тот же heap sort исполняет.
А графы да, всем чмоструктурам чмоструктуры, стэк нервно курит.
Братаны, спасибо за гачи, это то, что я ждал от вашего канала последние 14 лет! Лайк
На малых размерах памяти поиск в массиве быстрее, чем в дереве. Потому что кеш и строчное представление памяти. Поэтому листья дерева часто делают из небольших непрерывных кусков памяти, например в 64 байта.
Это где тебе может понадобится маленький на практике
Ля, чел ты просто топ. Запили видос по всем классическим паттернам с примерами из игр, про фабрики топ видос, сразу все стало понятно. А то смотришь челов которые снимают курсы и потом еще сидишь и пересматриваешь все что бы понять до конца
Лучшая интеграция :)
Одна из лучших
И 69 лайков у коммента )
@@furai911 хаххахах, люди шарят, люди не лайкают)))
Отдельная благодарность за подачу. Лучшая из возможных. Одновременно искренне и весело
да дерьмовая подача, вы чего?))
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще
РИЛЛ БАЛДЕЖ
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Можно пример имплементации стека на базе бинарного дерева, о которой вы упомянули? :)
А какие проблемы? Ну, кроме того что это будет несколько головоломно? Пару дополнительных переменных (начало и конец текущего состояния стека), механизм реализации (типа "добавляем вправо и вниз, вынимаем слева сверху"). И все дела.
@@EvgeniyFadeev ясно, ну, главное, мы все понимаем, что это прикол :) А так, с "дизайном" согласен :)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.♿
по просьбе автора, вот: "Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще." (c)
Виталяна смотришь?
Автор сам себя накручивает. Позор😔😔
@@haxidenti6001, ну это называется либо байт, либо рофел, а вообще ютуб сканит такие сообщения и выкидывает из учёта. Тупо написав 1 ботом 20к сообщений сыт не будешь
Я ассоциирую стек и очередь с микропроцессорами, они там вшиты и жизненно необходимы для работы. В программировании это может использоваться для хранения действий пользователя с их последующим откатом (ctrl-z), я их для себя называю "служебными".
Автор очевидно вебом занимается, хотя даже в js используется стек, когда функции вызываются например
Плюсую. Автор, конечно шарит, и его видосы топ. Но структуры данных это не только про программирование. Очередь и стек это больше про железо. ИМХО, автор ниже уровня компилятора не опускался.
@@NexoElongur Тоже самое с константами было, мол они не нужны
Хотя в тех же микриках, где борьба за каждый бит памяти, это просто мастхев
Очереди в микропроцессорах?
@@kodirovsshik ну да, очередь микрокоманд, к примеру.
"Не надо мне тут скользить, как функциональщики". 😂😂
Автор ты просто мега крутой и подача огонь! 🔥
Не знаю, насколько ты прав. Сейчас буду читать комменты и разбираться. Но в любом случае помог посмотреть с другой стороны на эту тему.
Прошу продолжай делать ролики.
Реально годный видос, получил удовольствие от просмотра и с радостью пофлексил новыми знаниями перед друзьями
Нас в универе учили, что есть массивы, листы и деревья, а очередь со стеком - это частные случаи листа. Так что не всё так плохо :) Ясен пень, что натянуть очередь и стек можно и на массив, но всё же с листом это несколько логичнее. Естественно, я имею в виду связный(двусвязный) лист, а не тот лист, который на основе массива сделан XD
А нас в универе учили, что есть память, в ней лежит что-то и ты ходишь туда-сюда по этой памяти и как-то интерпретируешь это. И все эти типы данных - про то как можно ту или иную функциональность получить интерпретируя данные из этой вот памяти. Все.
как бы очередь и стек это не про программирование, а про железо, то, что погромисты называют стеком, к реальному стеку не имеет отношение в принципе
@@Dmytro-Tsymbaliuk гы... Ну ладно, как скажешь )))
Можно поинтересоваться, что за уник?)
Стек или очередь с поддержкой минимума/максимума/другой функции за О(1) легче понимать через те самые бесполезные стеки, чем через массивы. В этом случае интерфейс хоть и не играет мужыцкой функциональной роли, но тебе становится легче понимать что-то, что пишется на них. Так-то дерево отрезков какое-нибудь тоже можно натянуть на массив в большинстве задач, но убрав дерево отрезков и оставив массив, жизнь не всегда становится проще
Братан хорош! Давай вперед) Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще?
Мегахарош. В программировании не шарю, но темой интересуюсь и благодаря тому, что ты в использовании сложных терминов не сдерживаешься как буд то бы новый язык учу. Мемы кста тоже классные. Красавчик)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Пошёл к тимлиду и говорю делай меня сеньором я теперь структуры шарю. Ну он спросил какие. -структуры и чмоструктуры. Лид встал, собрал свои вещи со стола и сказал что это теперь моё место а сам пошёл к большим дядькам просить мне зп как у СЕО.
Граница между "структурами" и "чмо-структурами" не такая уж и чёрно-белая, то же самое бинарное дерево можно запросто реализовать и через массив, что значительно ускорит некоторые операции, даст непрерывный кусок памяти под данное дерево, быстрый поиск и т.п.
виндертон - фуфло
Ага, ты только не ляпни такое при людях. Извращенец)
@@takiekakmi7532 Ох уж этот извращенец! На памяти экономит!
@@seriously1191 организовать адекватно работающий кастомный стек на проде - никто не даст. С большей вероятностью - тимлид отправит оптимизировать алгоритмическую составляющую🤷♂️ да и просто представь, что такой умник не добавил канарейку, прод наглухо умирает, данные слиты, потери по бабкам, и как итог - увольнение👌
Да но тогда сложность добавления элемента вырастает с logn до n.
Братан хорош! Давай вперёд! Контент в кайф! Можно ещё? Вообще красавчик! Можно вот этого почаще?
Братан, хорош! Давай вперёд! Контент в кайф, можно ещё? Вообще красавчик! Можно вот этого почаще.
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
Братан хорош!!! Давай, давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!
Братан, хорош!
Давай-давай, вперед!
Контент в кайф. Можно еще?
Ваще красавчик!
Вообще-то, используемый блок памяти может быть расположен в разных местах аллоцированного блока памяти!!!! Значит можно получить выигрыш в производительности!
Бро, контент огонь, давай еще! все джунам твои видосы в обязательную программу стажировки
Советую изучить тему абстрактных типов данных и не мешать их с структурами )
Братан, хорош, давай давай вперед, контент кайф!
Очередь и стек - полезные сущности, зря ты на них набросился) Согласен, что к отдельным структурам данных относить их не корректно - что одно, что второе по своей сути - массивы, только вот не с ограничивающим интерфейсом а завернутые в классы с логикой. Интерфейсами их поведения не добиться, увы. Что же до вопроса: "Зачем себя ограничивать когда есть мозги, прямые руки и здравый смысл" - не согласен в корне. Во первых: Такое ограничение - гарант, что сущность будет использована только теми способами, которые предусмотрел архитектор. Соблюдение этого условия - один из ключевых факторов в написании надёжного, сопровожаемого и расширяемого приложения. Во вторых: Это очень простые и понятные абстракции конкретизирующие принцип работы сущности, а использование абстракций - один из ключевых способов управления сложностью, что в свою очередь является главным императивом разработки програмного обеспечения. Твои нападки на эту истину - звучат как вопли яваскриптера-багодела, ничего сложнее хелоуворда не быдлокодившего)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!
Братан, хорош! Давай, давай вперёд. Контент в кайф! Можно ещё? Ваще красавчик! Можно вот этого почаще?
Молодец, мне уже сто лет примерно, но я угарнул отлично
Душнила на связи
при бинарном поиске по отсортированному массиву это будет равно поиску по дереву
Видимо автор изучает программирование по тик току
Братан хорош!!! Давай дв вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще
Можно вот этого почаще. Вообще красавчик! Можно еще? Контент в кайф. Давай вперед!! Братан хорош!!!
блин, я другую чмоструктуру применил, простите пацаны
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Побольше бы такого граммотного и структурированного (звиняюсь за каламбурю) контента на ютабе.
Есть такая вещь как абстрактные типы данных (АТД), где для каждого типа определен набор операций над ним. Словари, множества, те же стеки и очереди
А есть структуры данных, которые определяют реализацию АТД (смежные и связные)
И стек можно хоть на массиве, хоть на связном списке построить, суть в том чтобы поддерживать операции, определяющие стек и его поведение
Автор явно не прав, называя вещи не своими именами
Поиск в массиве при условии отсортированности имеет такую же алгоритмическую сложность, что и поиск в бинарном дереве, однако и проигрывает в таком случае по скорости вставки, удаления и т.п. Я считаю, что упущение этого факта, доказывает вашу несостоятельность и не квалифицированность, как программиста. Приберите за собой ваш кал, пожалуйста. (Это все шутка, мы вас любим❤)
Чего? Какой отсортированности? Вы по-моему теплое с мягким путаете.
Работа с данными не равна работе с ссылками на ячейки памяти
@@WildAntonOk вы кто?..
Вот что значит пришла молодежь не державшая в руках ни чего тяжелее компьютерной мышки.
Стек - структура поддерживаемая процессором. Там нет никакой надстройки сверху.
Очередь тоже поддерживается процессором. Тоже без надстроек.
Контент - на двойку на экзамене.
Эта КОРОБКА даёт ЛОГИКУ поведения.. которая как раз и зачастую нужна для программирования, а СПОСОБ хранения данных или "прохода по данным" это слегка про другое.. очевидные же вещи.. то же ДЕРЕВО это структура с определенной ЛОГИКОЙ поведения, так почему же не имеет право на жизнь СТЕК с ОПРЕДЕЛЕННОЙ ЛОГИКОЙ поведения.. ВСЕ структуры нужны, просто современные программисты скоро вообще НИЧЕМ пользоваться не будут, а тупо в редакторе мышкой накидали и в прод.. возможно если до автора не дошло ЗАЧЕМ нужны стеки и очереди, значит скорее всего он в своей жизни не писал ни чего сложнее сайтика на вордпрессе... других объяснений у меня для вас НЕТ..
Логика поведения это слишком общее описание. Цикл тоже задаёт логику поведения.
Способ хранения это тоже слишком общее описание. Оперативная память, HDD это тоже способ хранения.
Стек и очередь задают как возможно пользоваться данными, но не задают как эти данные организованы. Как пользоваться - это интерфейс, организация - это структуры.
@@Rayvenor естественно ОБЩЕЕ, всё в нашем мире можно представить в виде абстракции к абстракции(ну найти более высокий уровень).. так ведь и он же воду льёт замыливая суть ..а что только ЦИКЛ логика тут, а принцип доступа что уже не ЛОГИКА ? ну камон :)))))) я то отчасти согласен и с вами, кроме "Как пользоваться - это интерфейс, организация - это структуры" как раз структура в определенном языке как раз в себя включает И логику поведения И способ хранения.. ибо в разных языках реализация структуры(под капотом) может гулять но не сильно.. если вы измените поведение связного списка до стека, то это уже не будет связный список ввиду ограничений логики поведения, а станет СТЕКОМ... и пусть вас не путает ПОХОЖЕСТЬ... ибо всё по умолчания похоже и в программировании построено на бинарном принципе.. но мы же тогда не "ко ко ко" что типо а зачем структуры, если всё в итоге всё равно похоже на 1 0 1 0 1.. и только ЛОГИКА поведения на более высоком уровне абстракции делает из них их структуры..
@@artursword3288 Первую часть совершенно не понял.
"если вы измените поведение связного списка до стека, то это уже не будет связный список"
Тут вы смешиваете разные понятия, я не понимаю как на это ответить. Предлагаю изменить вопрос. Вопрос: Если бинарное дерево использовать как связный список, то это всё ещё бинарное дерево или уже связный список? Ответ: это ошибка проектирования структуры данных.
Другой вопрос: Если вы к структуре данных прикрутили интерфейс, то вы получили новую структуру данных или нет? Ответ: нет, структура данных не изменилась, иначе количество структур данных было бы равно количеству возможных интерфейсов, что практически бесконечность. Понятие структуры данных перестало бы что-то означать. Поэтому "как пользоваться" однозначно определяется "как организовано" и эта связка называется структурой данных. Вашими словами логика хранения задаёт логику использования. Если вам нужна другая логика использования - вы пишете коробочку, которая использует конкретную структуру данных, но не получаете новую уникальную структуру данных.
@@Rayvenor 1) вы сами ответили на свой вопрос :))))))) .. как раз это я и имел ввиду, что под свою задачу и ЛОГИКУ и была придумана структура данных с определенным ПОВЕДЕНИЕМ (как она там Хранит данные это уже вторично) и когда проектировщик выбирает модель он размышляет над ЛОГИКОЙ ПОВЕДЕНИЯ (например скорость поиска, скорость вставки, что ему необходимо в данный момент от данного условно хранилища)
2) "Если вы к структуре данных прикрутили интерфейс, то вы получили новую структуру данных или нет?" как раз так и делали, И со временем появились (как на примере с паттернами) устоявшиеся именованные структуры данных с доказанной полезностью, и сейчас когда говорят стек, то все понимают что имеется ввиду структура данных с принципом LIFO ... ведь так и по вашей же логике получается, что ЛЮБАЯ структура по сути имеет свою ЛОГИЧЕСКУЮ КОРОБОЧКУ над хранением... ну разве вы не видите своей же ошибки в дальнейшей логике? да и не получится их миллионы, ибо тут мы имеем ввиду БАЗОВЫЕ структуры, они по сути самодостаточны, а то что получится у вас будет, это просто синтез этих же самых структур, и в дальнейшем можно просто говорить о классификации их от уровня абстракции.. не дурные люди книжки писали... и мне уж точно смешно слышать как "блогер" затирает что "что то ему нужно" а "что то нет".. можете привести пример ДРУГИХ структур, которые по вашему мнению должны войти в "базовые", и которые отличаются только интерфейсом взаимодействия? в итоге вы и получите ТЕ САМЫЕ структуры которые у всех на слуху.. ибо их полезность уже доказана годами использования .. о вот в том что большинство умеет делать КОСТЫЛИ я и так уверен, воротить СВОИ структуры на базисе исходных, и верить, что они ПОЛЕЗНЫ., такое заблуждение скорее из-за плохого знания матчасти .. и это делают молодые разработчики.. проектируя я прежде всего думаю о поведении структуры (которое естественно, и тут вы правы, строится на внутренней реализации, как и скорость), у меня складывается мнение что вы моё "поведении структуры" путаете с ЛОГИКОЙ самой программы/модуля/куска кода.. в "двусвязном списке" же главное ЛОГИКА, туда сюда ходить, а не что он просто хранит данные, если мне не нужно туда сюда ходить я тупо выбирают другую структуру..
@@artursword3288 "ЛЮБАЯ структура по сути имеет свою ЛОГИЧЕСКУЮ КОРОБОЧКУ над хранением"
Разумеется, но есть одно отличие - ЯП не позволяет залезть под свой капот и использовать интерфейс более нижнего уровня. Поэтому отсчёт структуры как неделимой сущности начинается отсюда. По крайней мере мне это кажется логичным.
"проектируя я прежде всего думаю о поведении структуры (которое естественно, и тут вы правы, строится на внутренней реализации, как и скорость)" Проектируя свою структуру вы можете предсказать сколько места она будет занимать в памяти, какие операции будут работать быстро, а какие медленно, какие возможности она предоставит, а какие очно - нет. И это всё предсказывается на основе базовой структуры. Если вы узнаете, что некоторая структура была сделана на основе стека, вы сможете предсказать характеристики этой структуры? Мне кажется это сделать будет затруднительно без знания на базе чего был сделан стек.
Блин, зашёл в комментарии альтернативное мнение услышать, а в итоге разгребаю комментарии "Братан хорошо! Давай вперёд!..."
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик!
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще :D :D
За такую интеграцию - смотря рекламу до конца без перемотки и перехожу по ссылке! Заслужил!)))
@ExtremeCode А можно видосер про отличие структур данных (struct) от классов?
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Ну так смотря в каком языке программирования. В разных языках - разные отличия
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!!! Давай-давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан, хорош! Давай-давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого вот почаще?
Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще)
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще. Да побольше, побольше.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!
Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
7:50. Твой ава
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош! Давай-давай вперёд! Контент в кайф! Можно ещё? Вообще красавчик. Можно вот этого вот почаще?
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош! Давай вперед! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай, давай вперед!!! Контент в кайф. Можно ещё? Вообще красавчик! Можно вот этого вот почаще.
Братан хорош!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик!! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.
Братан хорош!!! Давай вперед!! Контент в кайф. Можно еще? Вообще красавчик! Можно вот этого почаще.