Is value type boxing when it is a field of reference type?

There is code:

struct A
{
   int b;
}

class B
{
  A a;
  int b;
}

Questions are:

1. Is a in B boxed or not?
2. Is a in B located in stack or in heap?
3. Is b in A boxed or not?
4. Is b in A stack or in heap?
5. Is b in B boxed or not?
6. Is b i开发者_如何学Pythonn B stack or in heap?

I really don't understand It :(

1) No, there's no boxing here.

2) a will be on the heap, although that's an implementation detail

3) No, b in A isn't boxed

4) b in A will live wherever the containing A will live (so with a local variable of type A it'll usually be on the stack; with an instance variable of a class like B or any static variable, it'll be on the heap); again, this is an implementation detail

5) b in B isn't boxed either

6) b in B will be on the heap - again, an implementation detail

There's no boxing going on here as you haven't shown anything trying to use a value type value as a reference type value (e.g. object or an interface).

Again, the whole stack/heap distinction is an implementation detail. You should read Eric Lippert's blog posts on the topic.

Using Google I found this:

Boxing and unboxing is a essential concept in C#’s type system. With Boxing and unboxing one can link between value-types and reference-types by allowing any value of a value-type to be converted to and from type object. Boxing and unboxing enables a unified view of the type system wherein a value of any type can ultimately be treated as an object. Converting a value type to reference type is called Boxing. Unboxing is an explicit operation.

Boxing is converting a value type to reference and that's not in you code. So answer to your "b-boxed" questions is "No".

1. The a member in B is not boxed.
2. The a member in B is located on the heap. It's part of the object, and objects are always allocated on the heap.
3. The b member in A is not boxed (but the A value may be boxed).
4. The b member in A is part of A, so it's stored wherever the A value is stored, which can be either on the stack or on the heap.
5. The b member in B is not boxed.
6. The b member in B is on the heap, as part of the object.

Passing a value type by reference is not boxing either.

void SomeFunction(ref int a) a is not boxed.

int? value Nullable value types are also not boxed.

object my_box = my_integer my_value is a boxed version of my_integer

Value types contained in classes are not boxed (when would it be a value type if that was the case?)

A storage location (variable, parameter, or field) of a structure type holds, within it, all of the fields--public and private--of that type. If the storage location is held on the stack as automatic variable or parameter, all of its fields will be likewise. If the storage location exists within a heap object, its fields will be within that same heap object.

Boxing works, internally, by defining for each value type a class type with the same name and members. When a value-type value is given to code which needs a class type, the system produces a new instance of the namesake class type and copies all the fields--public and private--from the value-type value to the the new object instance. Although the C# spec describes the boxed instance as being a value type, its behavior and internal workings will be those of a class type.