C # 中出现的装箱问题

我试图收集所有在 C # 中发生拳击的情况:

  • 将值类型转换为 System.Object类型:

    struct S { }
    object box = new S();
    
  • Converting value type to System.ValueType type:

    struct S { }
    System.ValueType box = new S();
    
  • Converting value of enumeration type to System.Enum type:

    enum E { A }
    System.Enum box = E.A;
    
  • Converting value type into interface reference:

    interface I { }
    struct S : I { }
    I box = new S();
    
  • Using value types in C# string concatenation:

    char c = F();
    string s1 = "char value will box" + c;
    

    注意: char类型的常量在编译时被连接起来

    注意: 自从6.0 C # 编译器 优化连接涉及到 boolcharIntPtrUIntPtr类型

  • 从值类型实例方法创建委托:

    struct S { public void M() {} }
    Action box = new S().M;
    
  • Calling non-overridden virtual methods on value types:

    enum E { A }
    E.A.GetHashCode();
    
  • Using C# 7.0 constant patterns under is expression:

    int x = …;
    if (x is 42) { … } // boxes both 'x' and '42'!
    
  • Boxing in C# tuple types conversions:

    (int, byte) _tuple;
    
    
    public (object, object) M() {
    return _tuple; // 2x boxing
    }
    
  • Optional parameters of object type with value type default values:

    void M([Optional, DefaultParameterValue(42)] object o);
    M(); // boxing at call-site
    
  • Checking value of unconstrained generic type for null:

    bool M<T>(T t) => t != null;
    string M<T>(T t) => t?.ToString(); // ?. checks for null
    M(42);
    

    注意: 在某些.NET 运行时中,这可能会被 JIT 优化

  • 使用 is/as运算符的无约束或 struct通用类型的类型测试值:

    bool M<T>(T t) => t is int;
    int? M<T>(T t) => t as int?;
    IEquatable<T> M<T>(T t) => t as IEquatable<T>;
    M(42);
    

    注意: 在某些.NET 运行时中,这可能会被 JIT 优化

据你所知,还有其他类似拳击的情况吗?

5027 次浏览

Calling non-virtual GetType() method on value type:

struct S { };
S s = new S();
s.GetType();

That’s a great question!

Boxing occurs for exactly one reason: when we need a reference to a value type. Everything you listed falls into this rule.

For example since object is a reference type, casting a value type to object requires a reference to a value type, which causes boxing.

If you wish to list every possible scenario, you should also include derivatives, such as returning a value type from a method that returns object or an interface type, because this automatically casts the value type to the object / interface.

By the way, the string concatenation case you astutely identified also derives from casting to object. The + operator is translated by the compiler to a call to the Concat method of string, which accepts an object for the value type you pass, so casting to object and hence boxing occurs.

Over the years I’ve always advised developers to remember the single reason for boxing (I specified above) instead of memorize every single case, because the list is long and hard to remember. This also promotes understanding of what IL code the compiler generates for our C# code (for example + on string yields a call to String.Concat). When your’e in doubt what the compiler generates and if boxing occurs, you can use IL Disassembler (ILDASM.exe). Typically you should look for the box opcode (there is just one case when boxing might occur even though the IL doesn't include the box opcode, more detail below).

But I do agree that some boxing occurrences are less obvious. You listed one of them: calling a non-overridden method of a value type. In fact, this is less obvious for another reason: when you check the IL code you don’t see the box opcode, but the constraint opcode, so even in the IL it’s not obvious that boxing happens! I won't get into the exact detail why to prevent this answer from becoming even longer...

Another case for less obvious boxing is when calling a base class method from a struct. Example:

struct MyValType
{
public override string ToString()
{
return base.ToString();
}
}

Here ToString is overridden, so calling ToString on MyValType won’t generate boxing. However, the implementation calls the base ToString and that causes boxing (check the IL!).

By the way, these two non-obvious boxing scenarios also derive from the single rule above. When a method is invoked on the base class of a value type, there must be something for the this keyword to refer to. Since the base class of a value type is (always) a reference type, the this keyword must refer to a reference type, and so we need a reference to a value type and so boxing occurs due to the single rule.

Here is a direct link to the section of my online .NET course that discusses boxing in detail: http://motti.me/mq

If you are only interested in more advanced boxing scenarios here is a direct link there (though the link above will take you there as well once it discusses the more basic stuff): http://motti.me/mu

I hope this helps!

Motti

  • Using the non-generic collections in System.Collections such as ArrayList or HashTable.

Granted these are specific instances of your first case, but they can be hidden gotchas. It's amazing the amount of code I still come across today that use these instead of List<T> and Dictionary<TKey,TValue>.

Adding any value type value into the ArrayList causes boxing:

ArrayList items = ...
numbers.Add(1); // boxing to object

Mentioned in Motti's answer, just illustrating with code samples:

Parameters involved

public void Bla(object obj)
{


}


Bla(valueType)


public void Bla(IBla i) //where IBla is interface
{


}


Bla(valueType)

But this is safe:

public void Bla<T>(T obj) where T : IBla
{


}


Bla(valueType)

Return type

public object Bla()
{
return 1;
}


public IBla Bla() //IBla is an interface that 1 inherits
{
return 1;
}

Checking unconstrained T against null

public void Bla<T>(T obj)
{
if (obj == null) //boxes.
}

Use of dynamic

dynamic x = 42; (boxes)

Another one

enumValue.HasFlag