Я, конечно, так себе программист, но в целом сталкивался с кодингом - и с программированием промышленной автоматики, и с игроделом, и даже когда-то в юности написал рабочую базу данных (на чём - не скажу, вообще засмеёте). Про стек слышал - первый пришёл, последний ушёл, это понятно. Можете на примере принглсов объяснить, где он практически применяется? Недавно в Stationeers добавили возможность использования стека, и я немного в растерянности: зачем, куда и как? Просветите игнорамуса пожалуйста. Хотя бы общую концепцию применения, дальше я сам.
раскрыть ветку (26)
Ну если кратко, то стэк нужен для хранения промежуточных вычислений и не нарушить их порядок.
раскрыть ветку (10)
В целом я такое объяснение слышал. Но когда у меня есть задача не нарушить порядок промежуточных вычислений, я организую вычисления и хранение промежуточных данных через переменные таким образом, чтобы его нельзя было нарушить. Для этого всё ещё не нужен стек. Так что, подозреваю, я что-то не понимаю на принципиальном уровне. Буду ждать статью.
раскрыть ветку (9)
Представь, что у тебя игра, где можно отменять ходы. И тогда лучший способ их хранить - стек. Или отмена операций в ворде, фотошопе и т.д.
раскрыть ветку (8)
Это могу представить, но полезность именно такого подхода в моём понимании достаточно ограничена. Я бы предпочёл иметь полностью контролируемый массив, в котором хранятся данные о прошлых операциях, и чтобы я мог по своему выбору обращаться к любой ячейке массива. В описании стека меня смущает именно ограниченность контроля над находящимися в нём данными.
раскрыть ветку (7)
Прикол в том, что стэк — это, ну, способ обращения к данным, а массив — это один из способов реализации хранения данных в памяти. Стеки и очередь, например, обычно на связных списках реализуются.
Со стэком мы обещаем, что можно положить только сверху и взять/посмотреть только сверху. То есть у тебя есть гарантия, что никто (даже ты сам) не влезет в кишки твоей структуры и не наведёт там панику и бардак. А меньше бардака — меньше ошибок. И если тебе нужна эта гарантия, то ты берёшь стэк.
Со стэком мы обещаем, что можно положить только сверху и взять/посмотреть только сверху. То есть у тебя есть гарантия, что никто (даже ты сам) не влезет в кишки твоей структуры и не наведёт там панику и бардак. А меньше бардака — меньше ошибок. И если тебе нужна эта гарантия, то ты берёшь стэк.
раскрыть ветку (5)
Это я понимаю. Я просто не представляю ситуации, в которой мне бы понадобился именно такой функционал. Как я уже говорил, я не то чтобы прям совсем программист. Поэтому многого не знаю, а о таких вещах узнаю в основном эмпирически, когда сталкиваюсь по необходимости. И как-то все эти годы не сталкивался с необходимостью именно такого функционала.
раскрыть ветку (4)
Ну языки и память для этого и создавали, чтобы ты в прикладных задачах сильно не парился за стэк. Значит он тебе был не нужен)
раскрыть ветку (1)
Согласен и поддерживаю) Я просто пытаюсь выяснить, как его можно применить в игре, о которой я говорил. Пока что так и не понял)))
Собственно, любая задача, где тебе важен именно порядок.
И да, мне самой всего пару раз встречались стеки/очереди (ну, не считая стеков вызова и стеков ошибок, гыг), но тем не менее, функционал этот нужен и полезен, хотя бы потому что ты можешь переложить часть ответственности за валидность данных на эту структуру.
И да, мне самой всего пару раз встречались стеки/очереди (ну, не считая стеков вызова и стеков ошибок, гыг), но тем не менее, функционал этот нужен и полезен, хотя бы потому что ты можешь переложить часть ответственности за валидность данных на эту структуру.
Стек обеспечивает безопасность взаимодействия с элементами, и не даёт лезть куда не надо.
Это архитектурные замуты в целом, но прикол в том, что тебе чтоб добраться до середины стека, надо обязательно выкинуть всё что выше. +Для списка/массива реализовывать аналоги push/pop - это ненужный гемор.
Я могу написать примеры конеш, но это всё сильно архитектурно обусловлено.
Это архитектурные замуты в целом, но прикол в том, что тебе чтоб добраться до середины стека, надо обязательно выкинуть всё что выше. +Для списка/массива реализовывать аналоги push/pop - это ненужный гемор.
Я могу написать примеры конеш, но это всё сильно архитектурно обусловлено.
Представьте, что вы решили в своей программе дать пользователю возможность отменить последнее действие. Сделали класс объектов, в который сохраняется инфа необходимая для отмены действия. И тут вам приходит в голову вопрос, а что если пользователь захочет отменить не одно последнее действие, а несколько... Тогда для хранения нескольких объектов с ифой для отмены действий пригодилась бы структура, из которой первым вытаскивается последний добавленный объект. И это стек.
раскрыть ветку (7)
Стэк это всего лишь структура данных. Ну да эта структура используется, чтобы знать, к какой команде вернуться после завершение процедуры (функции, метода). Но опять таки это всего лишь структура. К примеру он ещё может использоваться, как выделенный объект в куче, чтобы избежать рекурсии, чтобы не забивать стэк вызовов.
раскрыть ветку (5)
То при возвращении из подпрограммы из стека берётся старое значение и основная программа продолжается, как и была
раскрыть ветку (4)
А если мне нужно изменить регистр внутри подпрограммы, и чтобы после возвращения он имел новое значение?
раскрыть ветку (3)
Ты можешь менять только регистры или ячейки памяти, которые ты специально выделил для записи вычисляемых в подпрограмме значений. Чтобы регистры, используемые основной программой, не сбивались. Иначе будут непредсказуемые глюки
раскрыть ветку (2)
То есть по факту выделенные регистры - это переменные. В Stationeers есть встроенный язык программирования на базе MIPS. С MIPS я не работал, а в Stationeers программировал. Там буквально в начале программы происходит именование регистров как переменных, но имеется отдельный регистр с адресом возврата. Но у этих поименованных регистров сквозное применение через всё тело программы, включая подпрограммы. Что в теории даёт мне использование стека, если я уже могу использовать именованные переменные?
Stationeers - это игра в жанре инженерной выживалки в космосе. Немного похоже на Space Engineers, но ламповей и с более глубоким погружением в детали. Программирование там используется для организации систем промышленной автоматики, систем жизнеобеспечения и вообще всего, что можно только придумать. Последнее, что я там программировал - автоматизированную систему сбора урожая гидропоники.
Ты пытаешься объяснить человеку, про тот стек вызовов, не объясняя человеку что такое адресное пространство процесса и как оно разделяется. Опять таки, есть смысл говорить про стек возвратов, если мы работаем с регистровой машиной. Регистровая машина, как модель вычислений победила по той причине, что в ней проще реализовать прерывания работы процесса. Не стоит объяснять сложное, пока не объяснишь перед этим много простого.
В алгоритмах на графах, для реализации RPO нумерации стек нужен. Конечные автоматы с магазинной памятью. В конце концов стек программы (их может быть несколько в ОС с аппаратной поддержкой)
Ну я сейчас рассматриваю тему КС-языков и их разбора. Там что-то написано про МП-автоматы. Возможно, через длительное время выдам статью про стэковые машины, когда дойду до темы перевода языков. А вообще ищи инфу по стэковым машинам. Заодно с польской нотацией познакомишься.
раскрыть ветку (3)
раскрыть ветку (2)
раскрыть ветку (1)
Это был XT8086, MS-DOS, начало 90-х. Написал матери на работу базу данных, они ей несколько лет пользовались)
IT-юмор
7.5K постов53.3K подписчиков
Правила сообщества
Не публикуем посты:
1) с большим количеством мата
2) с просьбами о помощи
3) не относящиеся к IT-юмору