[c#] 구조체가 인터페이스를 구현하는 것이 안전합니까?

이 답변을 명시 적으로 제공 한 사람이 없기 때문에 다음을 추가합니다.

구현 구조체의 인터페이스 것은 어떠한 부정의 결과가 없습니다.

구조체를 보유하는 데 사용되는 인터페이스 유형의 모든 변수 는 해당 구조체의 박스형 값이 사용됩니다. 구조체가 변경 불가능한 경우 (좋은 점) 다음과 같은 경우가 아니면 최악의 성능 문제입니다.

• 잠금 목적으로 결과 객체 사용 (어쨌든 매우 나쁜 생각)
• 참조 같음 의미 체계를 사용하고 동일한 구조체의 두 개의 박스형 값에 대해 작동 할 것으로 예상합니다.

둘 다 가능성이 낮고 대신 다음 중 하나를 수행 할 가능성이 있습니다.

제네릭

인터페이스를 구현하는 구조체에 대한 많은 합리적인 이유는 제약 조건이 있는 일반 컨텍스트 내에서 사용할 수 있기 때문일 것 입니다. 이 방식으로 사용할 때 변수는 다음과 같습니다.

class Foo<T> : IEquatable<Foo<T>> where T : IEquatable<T>
{
    private readonly T a;

    public bool Equals(Foo<T> other)
    {
         return this.a.Equals(other.a);
    }
}

1. 구조체를 유형 매개 변수로 사용 가능
   • new()또는 같은 다른 제약 조건 class이 사용 되지 않는 한 .
2. 이러한 방식으로 사용되는 구조체에서 권투를 피할 수 있습니다.

그러면 this.a는 인터페이스 참조가 아니므로 그 안에 배치 된 상자를 생성하지 않습니다. 또한 C # 컴파일러가 제네릭 클래스를 컴파일하고 Type 매개 변수 T의 인스턴스에 정의 된 인스턴스 메서드의 호출을 삽입해야하는 경우 제한된 opcode를 사용할 수 있습니다 .

thisType이 값 유형이고 thisType이 메소드를 구현하는 경우 ptr은 thisType에 의한 메소드 구현을 위해 호출 메소드 명령에 대한 ‘this’포인터로 수정되지 않은 상태로 전달됩니다.

이것은 boxing을 피하고 값 유형이 구현하기 때문에 인터페이스는 메소드 를 구현 해야 하므로 boxing이 발생하지 않습니다. 위의 예에서 Equals()호출은 this.a ^1에 상자없이 수행됩니다 .

저 마찰 API

대부분의 구조체는 비트 단위로 동일한 값이 ² 로 간주되는 원시적 의미 체계를 가져야 합니다. 런타임은 이러한 동작을 암시 적으로 제공 Equals()하지만 속도가 느릴 수 있습니다. 또한 이러한 암시 적 동등성은 의 구현으로 노출 되지 않으므로IEquatable<T> 명시 적으로 구현하지 않는 한 사전의 키로 구조체가 쉽게 사용되는 것을 방지합니다. 따라서 많은 공용 구조체 형식 이 CLR BCL 내의 많은 기존 값 형식의 동작과 일치 할뿐만 아니라 더 쉽고 더 나은 성능을 제공하기 위해 구현 IEquatable<T>( T자체 위치 ) 을 선언하는 것이 일반적 입니다.

BCL의 모든 기본 요소는 최소한 다음을 구현합니다.

• IComparable
• IConvertible
• IComparable<T>
• IEquatable<T>(따라서 IEquatable)

많은 사람들 IFormattable이. 복소수 구조체 또는 일부 고정 너비 텍스트 값과 같이 유사하게 ‘넓게 유용한’유형을 구현하는 경우 이러한 공통 인터페이스를 많이 구현하면 (올바르게) 구조체가 더 유용하고 사용 가능해집니다.

제외

분명히 인터페이스가 변경 가능성을 강하게 암시하는 경우 (예 🙂ICollection 구현하는 것은 구조체를 변경 가능하게 만들 었는지 여부를 의미 하므로 나쁜 생각입니다 (원본이 아닌 박스형 값에서 수정이 발생하는 곳에서 이미 설명 된 종류의 오류로 이어집니다. ) 또는 Add()예외 와 같은 메소드의 의미를 무시하여 사용자를 혼란스럽게합니다 .

많은 인터페이스는 변경 가능성 (예 :)을 의미하지 않으며 IFormattable일관된 방식으로 특정 기능을 노출하는 관용적 방법으로 사용됩니다. 종종 구조체의 사용자는 이러한 동작에 대한 복싱 오버 헤드에 대해 신경 쓰지 않습니다.

요약

불변 값 유형에 대해 현명하게 수행하면 유용한 인터페이스를 구현하는 것이 좋습니다.

---

메모:

1 : 컴파일러는 특정 구조체 유형 으로 알려져 있지만 가상 메서드를 호출해야하는 변수에 대해 가상 메서드를 호출 할 때 이것을 사용할 수 있습니다 . 예를 들면 :

List<int> l = new List<int>();
foreach(var x in l)
    ;//no-op

List에 의해 반환 된 열거자는 목록을 열거 할 때 할당을 피하기위한 최적화 인 구조체입니다 (일부 흥미로운 결과 포함 ). 열거 구현이 경우의 foreach의 의미는 그 지정 IDisposable후 Dispose()반복이 완료되면 호출됩니다. 분명히 이것이 boxed 호출을 통해 발생하면 열거자가 구조체 인 이점을 제거 할 수 있습니다 (실제로 더 나쁠 것입니다). 더 나쁜 것은 dispose 호출이 어떤 식 으로든 열거 자의 상태를 수정하는 경우 박스형 인스턴스에서 발생하고 복잡한 경우 많은 미묘한 버그가 발생할 수 있습니다. 따라서 이러한 상황에서 방출되는 IL은 다음과 같습니다.

IL_0001 : newobj System.Collections.Generic.List..ctor
IL_0006 : stloc.0
IL_0007 : 아니요
IL_0008 : ldloc.0
IL_0009 : callvirt System.Collections.Generic.List.GetEnumerator
IL_000E : stloc.2
IL_000F : br.s IL_0019
IL_0011 : ldloca.s 02
IL_0013 : System.Collections.Generic.List.get_Current 호출
IL_0018 : stloc.1
IL_0019 : ldloca.s 02
IL_001B : System.Collections.Generic.List.MoveNext 호출
IL_0020 : stloc.3
IL_0021 : ldloc.3
IL_0022 : brtrue.s IL_0011
IL_0024 : 떠나다 .s IL_0035
IL_0026 : ldloca.s 02
IL_0028 : 제한됨. System.Collections.Generic.List.Enumerator
IL_002E : callvirt System.IDisposable.Dispose
IL_0033 : 아니요
IL_0034 : 최종적으로

따라서 IDisposable의 구현은 성능 문제를 일으키지 않으며 Dispose 메서드가 실제로 어떤 작업을 수행하는 경우 열거 자의 (유감스러운) 변경 가능한 측면이 유지됩니다!

2 : double 및 float는 NaN 값이 같지 않은 것으로 간주되는이 규칙의 예외입니다.