Як росте стек пам'яті

Подання купи та стеку

так а доступ у купі проходить повільніше ніж у стеку. Чи це приходить на програмному, а не апаратному рівні?

Може автор вивчає питання віртуальної пам'яті - так, купа та стек можуть опинитися на жорсткому диску, якщо їх туди засвопить операційна система. Інше питання, що стек в даному випадку це якийсь сегмент (область пам'яті) програми, а купа буде в сегменті даних (з атрибутами RW), на противагу сегменту коду (який RO). А взагалі дивно говорити про такі речі – треба відокремлювати мух від котлет і тепле не заважати м'яким.

@voipp, а чому Ви вирішили, що стек швидкий, а купа повільна? Наскільки мені відомо, час доступу до пам'яті в них однакове.

@voipp: Мені не здається, що інформація, яку ви прочитали, відповідає дійсності. Як правильно сказав @DreamChild, і стек, і хіп - не більше ніж апаратура. Те, що стек менше хіпу за розміром у типовому випадку, не означає нічого: ви можете звертатися до даних локально у хіпі та нелокально у стеку. (Ви мали на увазі кешування на рівні процесора, але воно працює не так, як ви думаєте.) Реєстрів у мовах високого рівня немає і не буде ніколи з багатьох причин (наприклад, тому, що компілятор, що оптимізує, вміє оптимізувати краще людини.)

3 відповіді 3

І стек і купа обидва знаходяться фізично в RAM (не розглядаємо архітектурні вивихи з використанням спец. процесорів/компів)
Їх розміри та розташування визначаються віссю
При цьому купа може бути фрагментована (іноді досить сильно). Зазвичай осі мають спеціальні процедури для дефрагментації купи.
Стек зазвичай ніколи не фрагментований (напевно, можна придумати реалізації стека з фрагментацією, але це оксюморон).
Стек як би швидше тому, що у нього єдиний параметр з яким працює - це покажчик положення стека (зазвичай регістр) - тому всі операції зі стеком працюють у рази швидше, ніж з купою. Операція вилучення/запису зі стека це 1 рух руху процесора POP/PUSH
З купою складніше саме через його фрагментацію і проста операція отримання значення з нього може вилитися в десятки (якщо не сотні) рухів процесора.
Мінуси стека в невеликій мірі його розміру (він завжди в порівнянні з купою на порядок менше) - ну і в тому, що доступ до нього тільки послідовний.

@Barmaley: 6) Це має сенс для виділення пам'яті в купі, але якщо у вас є вказівник на об'єкт у купі, і вказівник на об'єкт у стеку, швидкість доступу строго однакова. 7) Знову ж таки, доступ ведеться не послідовним читанням, а розйменуванням покажчика.

Справді, швидкість доступу до даних у стеку та купі однакова. Тобто. пункти 5) та 6) це помилка. Я не полінувався і перевірив час заповнення (кілька спроб) масиву із 2 млн. int (більше у стек у мене не влазить) у купі та стеку. void fill (int a [], int n) < srand (0); for (int i = 0; i < n; i++) a[rand() % n] = rand(); >Такий метод обраний, щоб мінімізувати вплив кешу та передвиборки даних до нього. Результати (clock_gettime(CLOCK_THREAD_CPUTIME_ID, &ts);) ./a.out 100 stack: avg: 43.332 (msec) heap: avg: 42.283 (msec)

@avp треба не так пробувати, треба домогтися того, щоб купа фрагментувалася - з цією метою треба зробити хмару рандомних алокацій різного розміру і також хаотично їх видаляти, тільки після цього перевірте швидкість доступу до великого масиву в купі. А інакше якщо купа не фрагментована швидкість, звичайно, буде однаковою.

@Barmaley ♦, у будь-якому випадку весь масив у купі перебуватиме у послідовних осередках (природно, у віртуальному адресному просторі). Або Ви розглядаєте теоретично можу в cc-NUMA ситуацію, коли ОС виділяє процесу пам'ять (mmap-ом?) з фізичної пам'яті іншого вузла? - На жаль, по-перше, зараз у мене немає доступу до подібної системи, ну, а по-друге, я не дуже уявляю, як змоделювати в cc-NUMA таку стійко повторювану ситуацію.

@Barmaley ♦, а фізична пам'ять може бути фрагментована, що у купі, що у стеку, що у коді. Але тут Ви помиляєтеся, на швидкість доступу (у звичайних, а не NUMA архітектурах) це не впливає.

Хоч і пройшло багато часу відколи ви поставили питання, хотілося б відповісти, адже все одно це питання "гуглиться" і, я думаю, що багато хто ще відвідає цю сторінку.

Як вам уже відповіли "фізично" - це транзистори та конденсатори. Отже, саме питання швидше за все було поставлене не зовсім коректно. Напевно, ви мали на увазі щось на зразок - "Де знаходиться купа і стек, як вони влаштовані".

Також , напевно , вас цікавить як в цілому влаштована пам'ять, повністю висвітлити це питання у мене не вийде, але я хочу вам показати вичерпний на мій погляд матеріал і дати посилання на них. Матеріали російською. Вам потрібно розібратися, що таке віртуальна пам'ять і як вона транслюється у фізичну.

Ось приклад організації сегментної пам'яті.

Суть у тому, що адресна вистава у "віртуальній пам'яті" відрізняється від фізичної. Але для процесу (програми) це важливо, т.к. розподілом пам'яті (виділенням/визволенням) займається не вона. Цим займаються різні механізми ОС та MMU

Для більш глибинного розуміння, вам потрібно ознайомитися з поняттям "віртуальна пам'ять", а також зі способами організації "Сегментна адресація пам'яті", "Сторінкова пам'ять"

Це коротко і трохи з приводу подання віртуальної пам'яті у фізичну.

Щодо пристрою пам'яті всередині процесу:

Знову коротко, процес думає, що йому виділяється цілісний простір, в якому вже розміщуються області - "код", "стек", "купа".
Стек заповнюється та зростає при виклику нових методів у вільну область у бік ЗМЕНШЕННЯ адрес. Купа росте навпаки у бік ЗБІЛЬШЕННЯ адрес. За тим, щоб пам'яті вистачило, таки стежить ОС.

Що зберігається в блоці CODE, а також багато іншого ви можете дізнатися з рекомендованих мною матеріалів у цій відповіді.

Рекомендую читати в порядку, запропонованому мною статті до ознайомлення.

Ази пристрою пам'яті
Відома стаття "Що кожен програміст повинен знати про пам'ять"
Організація віртуальної пам'яті. Таблиці сторінок та інше.
Перетворення логічної адреси на лінійну.
Пристрій MMU
Елемент списку

Мені не зовсім зрозумілі "рейтингові відповіді" на ваше запитання, оскільки люди в них пішли, на мій некомпетентний погляд, на обговорення інших тем.

Як влаштовано пам'ять

Розбираємо як влаштована пам'ять на прикладі простої моделі. Знайомимося з поняттями «стек» та «купа».

Для чого мені розуміти моделі пам'яті?
Стародавні моделі пам'яті
Моделі пам'яті. Трохи ближче до реальності
Хто і як використовує пам'ять
Що відбувається зі стеком
Навіщо потрібна купа?
Вправа, вправа!
На співбесіді
1. Чи є JavaScript мовою, що інтерпретується?
2. Згадайте, як влаштована пам'ять, і спробуйте відповісти на запитання:
Оновлено 25 червня 2024

Для чого мені розуміти моделі пам'яті?

Копіювати посилання "Навіщо мені розуміти моделі пам'яті?" Скопійовано

При вивченні нової мови програмування, ви швидко напишіть свій перший Hello, world! і почнете використовувати змінні.

Так відбувається, наприклад, коли навчаєте JavaScript. А от якщо вивчаєте Haskell, Hello, world! стане для вас нагородою після прочитання першої половини книги 🙂 І «змінні» виявляться «постійними».

Але що справді відбувається під час створення чи присвоєння змінних, і як виконуються функції? У всіх цих процесах бере участь пам'ять. Якщо ви зрозумієте, як вона влаштована, буде значно простіше використовувати інструменти розробника і легше відповісти на питання, пов'язані з пам'яттю.

Стародавні моделі пам'яті

Скопіювати посилання "Стародавні моделі пам'яті" Скопійовано

У давнину, коли комп'ютери тільки винаходили, було запропоновано дві моделі їхнього пристрою:

Ці архітектури багато в чому схожі: процесор виконує різні операції з даними. Яку саме операцію виконати визначає інструкція. Інструкції та дані надходять до процесора з пам'яті. Пам'ять розділена на осередки, кожен осередок дбайливо пронумеровано. Номер комірки називається адресою пам'яті. Адреса – величина фіксованої довжини. Процесор може звертатися до будь-якого осередку, не обов'язково робити це по порядку. Якщо дані не влазять в одну комірку, їх можна розмістити в кількох.

Основна відмінність між цими моделями полягає в тому, як саме зберігаються інструкції та дані. У Гарвардській моделі дані та інструкції розділені, а в архітектурі Фон Неймана вони розміщуються в одному сховищі. Це означає, що процесор, який використовує дані та інструкції, діставатиме їх однаковим способом — за допомогою однієї шини.Використовуйте архітектуру Фон Неймана як ментальну модель, щоб уявити, що відбувається у пам'яті, коли запускається програма.

Насправді, у ваших комп'ютерах використовується гібрид двох архітектур. Наприклад, у найближчих до процесора кешах дані та інструкції розділені.

Кількість можливих адрес пам'яті визначається довжиною адреси. Довжина залежить від архітектури процесора. Наприклад, 64-бітна адреса дозволяє звернутися до 18446744073709552000 осередків пам'яті. Це приблизно 18 ексабайт 🤯

Моделі пам'яті. Трохи ближче до реальності

Скопіювати посилання "Моделі пам'яті. Трохи ближче до реальності" Скопійовано

Модель вище добре підходить для міркувань про роботу програми. Насправді все трохи складніше. Адреси, на які дивилися в попередньому розділі, віртуальні. Щоб звернутися до реальної адреси, вашому процесору потрібно перетворити віртуальний адреса в фізичний адреса осередку оперативної пам'яті.

Коли процесу потрібна пам'ять, операційна система видає процесу блок пам'яті, який називається сторінкою (page). Зазвичай розмір сторінки відносно невеликий - 4-8 Кб. Процесу можна видавати багато сторінок. Ці сторінки віртуальні шматочки пам'яті, які відображаються на фізичну пам'ять.

Хто і як використовує пам'ять

Скопіювати посилання "Хто і як використовує пам'ять" Скопійовано

Операційна система запускає програму у межах певного процесу. Для цього процесу виділяються ресурси та адресний простір – те, які адреси пам'яті може використовувати цей процес. Операційна система гарантує, що один процес не матиме доступу до пам'яті іншого процесу, якщо інший процес цього не дозволить.

В рамках процесу може існувати один чи кілька потоків. Для кожного потоку виділяється шматочок пам'яті.

Помнете, що це модель. Насправді хто і як запускає потік залежить від того, на чому і для чого пишете програму. Подивіться, наприклад, на POSIX Threads.

У цей шматочок пам'яті завантажується код програми, глобальні змінні та ще дещо. У цьому ж шматочку пам'яті виділяються дві важливі області: стек (stack) і купа (heap). Стек — це область пам'яті, яку легко виділяти.

Щоб виділити або видалити пам'ять на стеку, потрібно просто перемістити спеціальний покажчик. stack pointer (покажчик стека). Значення поточного покажчика зберігається в спеціальному регістрі процесора, що означає, що виділяти та видаляти пам'ять на стеку можна дуже швидко. Цей покажчик завжди вказує наступну вільну комірку пам'яті стека.

Дані на стеку можна читати. Дані потрібно покласти на стек, щоб їх записати. Ви не можете записати дані в довільну область стека, тільки в кінці. Також не можете видалити дані з довільної області стека, але можна перемотати покажчик стека. Це рівносильно видалення всіх даних.

Програма у процесі виконання активно працює зі стеком. Пам'ять для стека може закінчитися, тоді з'явиться всім відоме переповнення стеку (stack overflow).

Дуже популярна та відома картинка, яка пояснює все:

Стек та купа ростуть назустріч один одному 🤗

Що відбувається зі стеком

Скопіювати посилання "Що відбувається зі стеком" Скопійовано

Давайте подивимося на функцію підрахунку собачок count Dogs ( ). Вона приймає один аргумент - happy Dogs, створює всередині змінну sad Coefficient і як-то вважає кількість собачок.
```
function countDogs(happyDogs)    const sadCoefficient = 0.1;
return happyDogs + sadCoefficient * happyDogs;>
function
countDogs(happyDogs)

const sadCoefficient  =
0.1;
return happyDogs  + sadCoefficient  * happyDogs;
>
```
Щоб виконати цю функцію, потрібно покласти аргументи функції та локальні змінні на стек. Крім цього, потрібно розуміти, який код виконати після завершення функції. Для цього на стеку створюється stack_frame. У ньому зберігаються аргументи та локальні змінні. Після того, як функція виконається, стек кадр видаляється разом з усіма аргументами та змінними функціями. При створенні стек кадру використовується ще одна корисна штука – покажчик на кадр (frame pointer). Цей покажчик завжди вказує на активний кадр на стеку.

Давайте подивимося, що станеться, якщо захочемо порахувати собачок у консолі.
```
function logDogs()    console.log(countDogs(20), countDogs(9));>
logDogs();
function
logDogs()

console.log(countDogs(20),
countDogs(9));
>
logDogs();
```
1. На стеку створиться кадр для функції log Dogs ( ) .
2. Потім додасться кадр для першого виклику count Dogs (20).
3. Після виконання функції count Dogs (20) кадр видаляється.
4. Потім додасться кадр для другого виклику count Dogs (9).
5. Після виконання функції count Dogs ( 9 ) кадр видаляється.
6. Після виконання функції log Dogs ( ) кадр видаляється.
Фрейм для функції count Dogs ( ) міститиме аргумент функції (20) і локальну змінну ( sad Coefficient ).

Ви все ще пам'ятаєте, що це модель? JavaScript слабо типізований мову. Якщо це зважати, наша ментальна модель зламається.Щоб виділити на стеку пам'ять під аргументи та локальні змінні, потрібно знати, скільки пам'яті виділяти. Оскільки ми знаємо тип змінної, незрозуміло, скільки пам'яті під неї треба виділити. JavaScript робить деякі припущення про типи змінних і на їх основі виділяє пам'ять на стеку. Ці припущення можуть виявитися помилковими, але це зовсім інша історія.

Якщо в процесі виконання функції код викине помилку, відбудеться розмотування стеку (stack unwinding). Ви побачите у консолі знайомий stack trace.

Давайте модифікуємо функцію count Dogs ( ) і змусимо її викинути помилку.
```
function countDogs(happyDogs)    const sadCoefficient = 0.1;
if (happyDogs < 10)    throw new Error('Занадто мало веселих собачок!');
>
return happyDogs + sadCoefficient * happyDogs;>
function
countDogs(happyDogs)

const sadCoefficient  =
0.1;
if
(happyDogs  
10)

throw
new
Error('Занадто мало веселих собачок!');
>
return happyDogs  + sadCoefficient  * happyDogs;
>
```
Отримаємо наступний результат, коли запустимо код із цього прикладу в консолі браузера:
```
Uncaught Error: Занадто мало веселих собачок! at countDogs (:4:11) <-- ось кадр count dogs at logDogs (:2:30) <-- ось кадр logDogs at :1:1
```
Побачимо при розмотуванні стека, що спочатку буде видалено кадр count Dogs ( ) , а потім log Dogs ( ) . Після цього виконання коду припиниться.

Навіщо потрібна купа?

Копіювати посилання "Навіщо потрібна купа?" Скопійовано

Дані на стеку зберігаються недовго. Коли функція завершує своє виконання, всі дані видаляються. Крім цього, ви не можете покласти на стік дані довільного розміру.

Розглянемо функцію роботи з масивом create Dog Array().
```
function createDogArray()    const dogs = ['🐶', '🐶', '🐶']; // 3 елементи
if (Math.random() > 0.5)    dogs.push('🐶'); // а може і 4 елементи :)
>>
function
createDogArray()

const dogs  =
['🐶',
'🐶',
'🐶'];
// 3 елементи
if
(Math.random()
>
0.5)
 dogs.push('🐶');
// а може і 4 елементи :)
>
>
```
Ми створили масив із 3 елементів. Тепер потрібно покласти на стек змінну dogs, що містить цей масив. Для цього необхідно виділити місце під змінну. Все було добре, поки ми не вирішили випадково додати ще одну собачку. Виходить, що кількість елементів у масиві dogs невідомо, і незрозуміло, скільки пам'яті під нього потрібно виділити.

Ось як купа вирішує цю проблему: виділятиметься спеціальний шматочок пам'яті під масив. Адреса цього шматочка в пам'яті запам'ятовується і записується в dogs. Як ми знаємо, адреса має фіксований розмір, тому зможемо покласти змінну dogs з адресою на стек. Коли потрібно модифікувати масив, візьмемо адресу в купі, знайдемо за цією адресою масив і додамо в нього нового собачку.

Вправа, вправа!

Скопіювати посилання "Вправа, вправа!" Скопійовано

Тепер ви уявляєте як влаштована пам'ять та готові відповісти на запитання з початку статті.

Якщо у вас вийшло, надайте відповіді в розділ «На співбесіді».

На співбесіді

Скопіювати посилання "На співбесіді" Скопійовано

Чи є JavaScript мовою, що інтерпретується?

Скопіювати посилання "Чи є JavaScript мовою, що інтерпретується?" Скопійовано

Скопіювати посилання "Viktar Nezhbart відповідає" Скопійовано

Питання в такій постановці не має однозначної відповіді.

Насамперед згадаємо, які типи мов, залежно від способу трансляції (компіляції) вихідного коду в машинний код, бувають:

У компілюваної мови етап трансляції вихідного коду відбувається до виконання. Це вимагає аналізу всієї написаної програми цілком, проте дозволяє виявити багато помилок. До таких мов належать C, C++, Go.

У мов, що інтерпретуються, трансляція відбувається «на льоту» (рядок за рядком). Такий підхід забезпечує додаткову гнучкість та динамічні зміни на етапі виконання та вимагає менше часу для старту. До мов, що інтерпретуються, відносять «скриптові» мови: Perl, VBScript, PHP.

JavaScript іноді називають інтерпретованим, що вірно лише частково. Наприклад, якщо ми зробили друкарську помилку в назві константи, програма виконається до рядка з помилкою:
```
const a = 0console.log("1-ий рядок виконано")console.log(a2)
// Перший рядок виконано// console.log(a2)// ^// ReferenceError: a2 is not defined
const a  =
0
console.log("Перший рядок виконано")
console.log(a2)
// Перший рядок виконано
// console.log(a2)
// ^
// ReferenceError: a2 is not defined
```
У той же час, JavaScript не можна назвати інтерпретованим.

Спробуємо виконати програму, що містить синтаксичну помилку у другому рядку:
```
console.log("1-ий рядок виконано")console.log("2-ий рядок містить помилку"")
// SyntaxError: Неправильний або невідповідний фон
console.log("Перший рядок виконано")
console.log("Другий рядок містить помилку"")
// SyntaxError: Неправильний або невідповідний фон
```
Можна було очікувати, що спочатку виконається перший рядок, а потім виведеться повідомлення про помилку, але при виконанні отримуємо тільки повідомлення про помилку (текст повідомлення залежить від движка, наведено результат роботи в Node.js).

Ще один приклад, що спростовує рядкову інтерпретацію вихідного коду JavaScript — «підняття» (hoisting) при оголошенні функцій:
```
praise("Пушкін")// Ай так, Пушкін!
function praise(name)    console.log(`Ай так, $!`)>
praise("Пушкін")
// Ай так, Пушкін!
function
praise(name)

console.log(`Ай так,
$name>!`)
>
```
Сучасні движки JavaScript використовують JIT (just-in-time) компіляцію – підхід, що дозволяє оптимізувати код. Говорячи простою мовою, ідея полягає у спостереженні за тим, скільки разів виконується певна частина коду та які типи даних при цьому використовуються.
У першому етапі використовується інтерпретатор. Якщо якась частина коду, наприклад функція, виконується багаторазово, то для неї буде використано компіляцію та спробу оптимізації.

Підсумовуючи, можна сказати, що JavaScript не відноситься повністю ні до компілюваних, ні до інтерпретованих мов.

Згадайте, як влаштована пам'ять, і спробуйте відповісти на запитання:

Скопіювати посилання "Згадайте, як влаштовано пам'ять, і спробуйте відповісти на запитання:" Скопійовано
- Як надаються значення змінним?
- Що означає передача за посиланням та за значенням?
- Що означає дивний текст max call stack size exceeded у консолі?
Це питання без відповіді. Ви можете допомогти! Щоб написати відповідь, дотримуйтесь інструкцій.

Стек: що це таке та застосування

Стек - це феномен програмування та природне рішення. Стек одразу прийшов у комп'ютерну справу і став таким «рідним», ніби саме з нього починалося все.

Без стека не працює процесор, немає рекурсії та ефективні виклики функцій організувати неможливо. Будь-який алгоритм може обійтися без черги, списку, колекції, масиву чи системи організованих об'єктів, але без пам'яті та стеку не працює нічого, у тому числі все перераховане.

На зорі початку: процесор, пам'ять та стек

Ідеальна пам'ять забезпечує адресацію прямо до значення – це рівні машини та мови високого ступеня. У першому випадку процесор послідовно перебирає адреси пам'яті та виконує команди. У другому випадку програміст маніпулює масивами. В обох епізодах є:

Адреса може бути абсолютним та відносним, індекс може бути цифровим та асоціативним. За адресою та індексом може бути інша адреса, а не значення, але це деталі непрямої адресації. Без пам'яті процесор працювати не може, а без стека команд та даних – він, як човен без весел.

Стопка тарілок - традиційна новела про суть стека: поняття stack та переклад у загальнопобутовій свідомості. Не можна взяти тарілку знизу, можна брати лише згори, і тоді всі тарілки будуть цілі.

Все, що останнім приходить у стек, йде першим. Ідеальне рішення. По суті, stack, як переведення однієї дії в іншу, трансформує уявлення про алгоритм як послідовність операцій.

Суть та поняття стека

Процесор та пам'ять – основні конструктивні елементи комп'ютера. Процесор виконує команди, маніпулює адресами пам'яті, витягує та змінює значення за цими адресами. Мовою програмування усе це трансформується на змінні та його значення. Суть стека та поняття last in first out (LIFO) залишається незмінним.

Абревіатура LIFO не використовується так часто, як раніше.Ймовірно тому, що списки трансформувалися в об'єкти, а черги first in first out (FIFO) застосовуються в міру потреби. , а до цього моменту можна описувати будь-що і як завгодно.

Так, стек - що це таке?Тепер ви знаєте, що це питання недоречний. Механізм виклику значень без стека - це зайва робота, хоча досяжне рішення, безумовно, можливе.

Багато хто запитує: "Стек - що це таке?".
- збереження адреси повернення;
- збереження всіх змінних, що передаються, або адреси на них;
- виклик функції.
Як тільки ця функція виконає свою місію, вона просто поверне керування за адресою повернення Функція може викликати будь-яку кількість інших функцій, оскільки обмеження накладається тільки розміром стека.

Властивості стеку

Стек - це не абстрактний тип даних, а реальний механізм.

Характерні властивості стека - це його розмір та довжина елементів. На рівні процесора все визначається розрядністю, адресацією пам'яті та фізикою доступу до неї.Цікава особливість та традиція: стек росте вниз, тобто у бік зменшення адрес пам'яті, а пам'ять програм та даних – вгору. Це звичайно, але не обов'язково. Тут важливий сенс – прийшов останнім, а пішов першим. Це напрочуд просте правило дозволяє будувати цікаві алгоритми роботи насамперед мовами високого рівня. Тепер ви не питатимете, стек - що це таке.

Бездоганна робота апаратного забезпечення вже дуже давно є нормою, але на передовому краї інформаційних технологій ідея стека знаходить нові та перспективні застосування.

Насправді не важливо, що таке стек на рівні процесора. Це природна складова архітектури комп'ютера. Але в програмуванні стек залежить від конкретного застосування та здібностей програміста.

Масиви, колекції, списки, черги. Стек!

Часто люди запитують: "Стек - що це таке?". " Програмування " і " систематизація " - цікаві поняття: де вони синоніми, але тісно пов'язані. Програмування пройшло дуже швидко такий тривалий шлях, що досягнуті вершини здаються ідеальними. Швидше за все це не так. Але очевидно інше.

Ідея стека стала звичною не лише на рівні різних мов програмування, але й на рівні їх конструкцій та можливостей щодо створення типів даних. Будь-який масив має push і pop, а поняття "перший та останній елементи масиву" стали традиційними. Раніше були просто елементи масиву, а сьогодні є:
- елементи масиву;
- перший елемент масиву;
- останній елемент масиву.
Операція приміщення елемента масив зрушує покажчик, а вилучення елемента початку масиву чи з кінця має значення. По суті це той самий стек, але у застосуванні до інших типів даних.

Особливо примітно, що популярні мови програмування немає конструкції stack. Але вони надають його ідею розробнику у повному обсязі.