Вітаю, питання по ref type і value type. Якщо в нас

є клас Person:

class Person // клас - це ref type
{
public int Id { get; set; } // Int в нас value type
}

але ж через те, що INT в нас знаходиться в класі, то він все рівно розташований в кучі.

В мене є думка (чисто суб'єктивна і не підтверджена). Стек і куча поділені таким чином, що стек - зручний у швидкодоступності і туди засовують легкі дані, а куча - для розміщення більших даних. Класи - це в нас складний тип даних, тому його визначено розміщувати у кучі. І суто ТЕОРЕТИЧНО, ми могли б його і в стек засунути, але ми цього не робимо (чи CLR), бо в стека інші функції. І якщо, в нас умовно струкура, то вона засовується в стек, а якщо клас - то в кучу.

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

❓Питання відносно приклада описаного вище:
1) Як int в середині класа розташовується в кучі, якщо value type маює розташовуватися в стеку?
2) Чи можна вважати, що тут відбувається boxing?
3) Навряд мої думки коректні, стосовно визначення в пам'яті даних. Що я кажу не вірно?
4) Чи є якісь джерела, щоб почитати про те, як розташовується в пам'яті int, який знаходиться в класі?

Питання ти C чи С++ знаеш?

1. Boxing 2. Так 3. Стек не існує сам по собі (можу помилятися), він існує в контексті виконання функції. А от куча існує сама по собі

4. CLR via C# книжка в цьому плані класика, але вона досить сумбурна і я хз чи оновлювалася вона на дотнет кор

А принципово нічого майже не змінилося. Окрім CAS та AppDomain

А GAC?

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

Ну також. Але це не складно доволі. Strong naming майже не актуальні зараз

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

1) але в IL коді не пише про boxing

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

Boxing лише коли ти структури до object конвертуєш

Це правда, але приклад цікавий і не дуже складний, є більш задрочені питання

Тоді я здається некоректно відповів про боксінг у випадку коли структура це поле у класі

Ну там про value type на стеку це солодка не правда для спрощення. Через це описувати боксінг доводиться через огороди

Доповню відповідь номер 3 Стек у кожного thread окремий Там зберігається контекст виконання цього потоку Включно з локальними змінними та параметрами метода, що зараз викликаний Оскільки клас як сутність може одночасно бути використаний з декількох потоків – він ніяк не може лежати на стеку (як і його глобальні змінні, незалежно від ref/value type) І саме по цій причині будь-який навіть потенційний шанс виконання коду в іншому від поточного потоці викликає boxing (як приклад такої операції – delegate variable capturing) @yarikko

Я якраз вчора займався адаптацією блазорного рантайму до реалій threads + call stacks для юай дебагера

1) інлайниться в пам'ять класу 2) ніт 3) стек для даних фіксованого розміру (здебільшості, не дивлячись на всякі VLA) 4) статті в інетіку є, тей же https://learn.microsoft.com/en-us/archive/msdn-magazine/2005/may/net-framework-internals-how-the-clr-creates-runtime-objects

Стикер

сарказм чи внатурі?)

внатурі, я починав перекладати але потім поклав