Чому .Net книги говорять про розподіл пам'яті стека та купи?

Схоже, що кожна .net книга розповідає про типи значень проти типів посилань і робить його точкою (часто неправильно) стану, де зберігається кожен тип - купа чи стек. Зазвичай це в перших кількох главах і подається як якийсь важливий факт. Я думаю, що це навіть охоплюється сертифікаційними іспитами . Чому стек проти купи навіть має значення для початківців розробників? Net? Ви виділяєте речі, і це просто працює, правда?

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

Як зазначив Феде, Ерік Ліпперт має сказати про це дуже цікаві речі: http://blogs.msdn.com/b/ericlippert/archive/2010/09/30/the-truth-about-value-types.aspx .

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

Для тих, хто вважає, що це все ще важливо з міркувань продуктивності: Які дії ви вчинили б, щоб перенести щось із купи в стек, якби ви виміряли речі і дізналися, що це має значення? Швидше за все, ви знайдете зовсім інший спосіб підвищення продуктивності для проблемної області.

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

Я згоден повністю; Я це бачу весь час.

Чому книги .NET говорять про розподіл стека проти купи пам'яті?

Однією з причин є те, що багато людей прийшли до C # (або інших мов .NET) із C або C ++. Оскільки ці мови не застосовують для вас правил щодо тривалості зберігання, ви зобов'язані знати ці правила та уважно реалізовувати свою програму, щоб дотримуватися їх.

Тепер, якщо знати ці правила та виконувати їх у C, не потрібно, щоб ви розуміли "купу" та "стек". Але якщо ви розумієте, як працюють структури даних, то часто простіше зрозуміти та слідувати правилам.

Під час написання книги для початківців автор закономірно пояснює поняття в тому ж порядку, в якому їх вивчив. Це не обов’язково порядок, який має сенс для користувача. Нещодавно я був технічним редактором книги для початківців Скотта Дормана C # 4, і одна з речей, що мені сподобалась у тому, що Скотт вибрав досить розумне замовлення для тем, а не починаючи з того, що насправді є досить передовими темами управління пам’яттю.

Інша частина причини полягає в тому, що деякі сторінки документації MSDN сильно підкреслюють міркування щодо зберігання. Особливо старіша документація MSDN, яка все ще висить з перших днів. Значна частина цієї документації має тонкі помилки, які ніколи не були виправлені, і ви повинні пам’ятати, що вона була написана в певний час в історії та для певної аудиторії.

Чому стек проти купи навіть має значення для початківців розробників .NET?

На мою думку, це не так. Що важливіше зрозуміти - це такі речі:

• Чим відрізняється семантика копії між типом посилання та типом значення?
• Як поводиться параметр "ref int x"?
• Чому типи значення повинні бути незмінними?

І так далі.

Ви виділяєте речі, і це просто працює, правда?

Це ідеал.

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

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

Але це все прогресивні сценарії. В ідеалі програміст-початківець не повинен турбуватися ні про що з цього матеріалу.

Ви, хлопці, все пропускаєте. Причина, чому важливо відрізняти стек / купу, - це масштаб .

struct S { ... }

void f() {
    var x = new S();
    ...
 }

Після того, як x виходить за межі, об’єкт, який було створено, категорично відпадає . Це лише тому, що вона виділяється на стек, а не на купу. Немає нічого, що могло б увійти в "..." частину методу, що може змінити цей факт. Зокрема, будь-які призначення або виклики методів могли робити лише копії структури S, не створюючи нових посилань на неї, щоб вона могла продовжувати жити.

class C { ... }

void f() {
     var x = new C();
     ...
}

Зовсім інша історія! Оскільки x зараз знаходиться в купі , його об’єкт (тобто сам об’єкт , а не його копія) може дуже добре продовжувати жити після того, як x вийде з межі. Насправді, єдиний спосіб, коли він не буде продовжувати жити, це, якщо x - це єдине посилання на нього. Якщо призначення або виклики методу в частині "..." створили інші посилання, які досі "живуть" до того моменту, коли х вийде за межі, то цей об'єкт продовжить жити.

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

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

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

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

Я мало знаю про .NET, але наскільки я знаю, його JITted перед виконанням. Наприклад, JIT може виконати аналіз втечі, а що ні, і раптом у вас будуть предмети, що лежать на стеці або просто в деяких регістрах. Ви не можете цього знати.

Я припускаю, що деякі книги висвітлюють це просто тому, що автори приписують йому велике значення або тому, що вони припускають, що їх аудиторія робить (наприклад, якщо ви написали "C # для програмістів на C ++", ви, ймовірно, повинні висвітлювати цю тему).

Тим не менш, я думаю, що не можна сказати набагато більше, ніж "керованою пам'яттю". Інакше люди можуть зробити неправильні висновки.

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

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

Однак здебільшого це досить академічно.

Як ви кажете, C # повинен абстрагувати управління віддаленою пам’яттю, а розподіл купівлі проти стека - це деталі реалізації, про які теоретично розробникові не потрібно знати.

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

Зауважте, що книги про скажімо Python чи JavaScript не зроблять нічого із цього, якщо вони навіть згадують про це. Це тому, що все або виділяється купою, або незмінне, а це означає, що різні семантики копіювання ніколи не вступають у дію. У цих мовах працює абстракція пам’яті, в C # вона є герметичною.