Какой смысл в boxing/unboxing?

Question

[Василий Васильев]

Сам процесс вроде как понятен - мы перебрасываем, грубо говоря, данные из стека в кучу и наоборот, что занимает кучу времени и вообще штука вроде как совершенно ненужная, ибо с кучей работать в принципе дольше. Отсюда и вопрос - какой, так сказать, практический толк в данной "фиче"?

Answer 1

[eRKa]

Иногда есть необходимость работать с чем то обобщенным, абстрагироваться от конкретного типа. Например при сериализации в json для отправки данных клиенту, как то так

public string ResponseData(object value)
{
	retrun JsonConvert.Serialaze(value);
}

Теперь мы может одним методом отправить хоть объект, хоть значимый тип. Если бы не было упаковки, пришлось бы писать кучу перегрузок для метода.

Comments

[eRKa]

Alex Ander, каст/апкаст это один тип объекта к другому типу, эта процедура не дорогая (но это не значит что ее можно пихать во все дыры). А вот упаковка/распаковка (значимый тип к object) это дорого.

Answer 2

[Дмитрий Черняков]

Смотрите это как на инструмент, вытекающий из механизма ООП(а точнее наследования) в языке C#.

Вот цитата из довольно развёрнутого ответа на такой же вопрос:
Источник цитаты

Чтобы иметь унифицированную систему типов и разрешать типы значений иметь совершенно иное представление своих базовых данных от того, как ссылочные типы представляют их базовые данные (например, int - это просто ведро из тридцати двух бит, которое полностью отличается от ссылочного типа).

Подумайте об этом так. У вас есть переменная o типа object. И теперь у вас есть int, и вы хотите поместить его в o. o является ссылкой на что-то где-то, а int категорически не является ссылкой на что-то где-то (в конце концов, это просто число). Итак, что вы делаете, так это: вы создаете новый object, который может хранить int, а затем вы назначаете ссылку на этот объект на o. Мы называем этот процесс "боксом".

Итак, если вам не нужно иметь унифицированную систему типов (т.е. ссылочные типы и типы значений имеют очень разные представления, и вам не нужен общий способ "представить" эти два), то вы не нужен бокс. Если вам не нужно, чтобы int представляло их базовое значение (т.е. Вместо этого int тоже были ссылочными типами и просто сохраняли ссылку на их базовое значение), вам не нужен бокс.

Comments

[Vitaliy Orlov]

"int - это просто ведро" - насмешило :)

Вот оригинал: stackoverflow

Why

To have a unified type system and allow value types to have a completely different representation of their underlying data from the way that reference types represent their underlying data (e.g., an int is just a bucket of thirty-two bits which is completely different than a reference type).

Think of it like this. You have a variable "o" of type object. And now you have an int and you want to put it into "o". "o" is a reference to something somewhere, and the int is emphatically not a reference to something somewhere (after all, it's just a number). So, what you do is this: you make a new object that can store the int and then you assign a reference to that object to "o". We call this process "boxing."

So, if you don't care about having a unified type system (i.e., reference types and value types have very different representations and you don't want a common way to "represent" the two) then you don't need boxing. If you don't care about having int represent their underlying value (i.e., instead have int be reference types too and just store a reference to their underlying value) then you don't need boxing.

Where should I use it.

For example, the old collection type ArrayList only eats objects. That is, it only stores references to somethings that live somewhere. Without boxing you cannot put an int into such a collection. But with boxing, you can.

Now, in the days of generics you don't really need this and can generally go merrily along without thinking about the issue.

[Дмитрий Черняков]

Vitaliy Orlov, спасибо за оригинал, было интересно. Как-то сразу и не понял, что это перевод с stackoverflow, хотя там была ссылка на него.