C# 7.3 - unmanaged(blittable) 제네릭 제약

C# 7.3 (1) - 개선된 문법 4개(Support == and != for tuples, Ref Reassignment, Constraints, Stackalloc initializers)
; https://www.sysnet.pe.kr/2/0/11552

C# 7.3 (2) - 개선된 메서드 선택 규칙 3가지(Improved overload candidates)
; https://www.sysnet.pe.kr/2/0/11553

C# 7.3 (3) - 자동 구현 속성에 특성 적용 가능(Attribute on backing field)
; https://www.sysnet.pe.kr/2/0/11554

C# 7.3 (4) - 사용자 정의 타입에 fixed 적용 가능(Custom fixed)
; https://www.sysnet.pe.kr/2/0/11555

C# 7.3 (5) - 구조체의 고정 크기를 갖는 fixed 배열 필드에 대한 직접 접근 가능(Indexing movable fixed buffers)
; https://www.sysnet.pe.kr/2/0/11556

C# 7.3 (6) - blittable 제네릭 제약(blittable)
; https://www.sysnet.pe.kr/2/0/11558

C# 7.3 (7) - 초기화 식에서 변수 사용 가능(expression variables in initializers)
; https://www.sysnet.pe.kr/2/0/11560

---

C# 문서에 보면,

Language Feature Status
; https://github.com/dotnet/roslyn/blob/master/docs/Language%20Feature%20Status.md

C# 7.3의 새로운 기능으로 "blittable"이라고 명시한 것을 볼 수 있습니다. 제안된 기록들을 보면,

Champion "blittable"/"unmanaged" constraint (15.7) #187
; https://github.com/dotnet/csharplang/issues/187

Initial blittable proposal #206
; https://github.com/dotnet/csharplang/pull/206

csharplang/proposals/csharp-7.3/blittable.md - Unmanaged type constraint
; https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.3/blittable.md

blittable이라고 자주 언급하고 있지만 예약어로는 "unmanaged"가 된 것으로 보입니다. 그리고 이 unmanaged 제네릭 제약은 이미 전에도 간단하게 언급을 했었습니다.

C# 7.3에서 개선된 문법 4개(Support == and != for tuples, Ref Reassignment, Constraints, Stackalloc initializers)
; https://www.sysnet.pe.kr/2/0/11552

위의 글에서 설명했듯이, C# 7.3에 추가된 제네릭 제약에 관한 예약어가 Delegate, Enum과 unmanaged가 있는데 delegate와 enum은 직관적으로 알 수 있으니 생략하고 이번 글에서는 blittable일 뻔했던 unmanaged에 대해 좀 더 설명해 보겠습니다.

---

unmanaged 제약의 설명에 blittable이 나오므로 지난 글에서 한번 정리해 봤지만,

C# - blittable 타입이란?
; https://www.sysnet.pe.kr/2/0/11557

사실 위에서 정리한 blittable 타입이 unmanaged 제약이 요구하는 blittable 타입과 일치하지는 않습니다. 차이점은 대략 다음과 같은 정도입니다.

• LayoutKind.Auto 유형의 struct를 unmanaged는 허용
• 모든 참조 형식에 대해서는 unmanaged는 불가(가령 int [] 배열도 unmanaged는 허용하지 않음)
• System.Boolean, System.Char에 대해 unmanaged는 허용

그런데, LayoutKind.Auto 유형은 필드 배치가 바뀔 수도 있는데 어떻게 허용하게 된 걸까요? 왜냐하면, LayoutKind.Auto일지라도 참조 형식의 필드를 포함하지 않는다면 필드 배치가 바뀌지 않기 때문입니다. 따라서 위에서 2번째 조건이었던 "모든 참조 형식에 대해서는 unmanaged는 불가"로 인해 LayoutKind.Auto도 허용이 되는 것입니다.

간단하게 보면, unmanaged 제약은 기존 struct 제약의 좀 더 특수화한 사례에 속합니다. 즉, struct 제약 중에서 대상 타입이 참조 형식을 필드로 갖지 않는다는 보장을 하나 더 해줍니다. 코드로 설명하기 위해 다음과 같은 타입을 만들고,

class CallGenerics
{
    public static void AcceptBlittable<T>(T item) where T : unmanaged
    {
    }

    public static void AcceptStruct<T>(T item) where T : struct
    {
    }
}

string 타입에 대해 AcceptBlittable과 AcceptStruct 메서드를 호출하면 다음과 같은 컴파일 오류가 발생합니다.

{
    System.String txt = "TEST";

    // 컴파일 에러 - Error CS8377 The type 'string' must be a non-nullable value type, along with all fields at any level of nesting, in order to use it as parameter 'T' in the generic type or method 'CallGenerics.AcceptBlittable<T>(T)'
    CallGenerics.AcceptBlittable(txt); 

    // 컴파일 에러 - Error CS0453 The type 'string' must be a non-nullable value type in order to use it as parameter 'T' in the generic type or method 'CallGenerics.AcceptStruct<T>(T)'
    CallGenerics.AcceptStruct(txt);
}

보는 바와 같이 오류 메시지에서 명확한 제약 조건을 확인할 수 있습니다. 우선, struct 제약은 "non-nullable value type"으로 (C# 2.0에 추가된 nullable이 아닌) 값 형식이기만 하면 됩니다. 반면 unmanaged는 "along with all fields at any level of nesting"이라는 하나의 조건이 더 있습니다. 따라서 실제로 blittable한 것을 평가하기보다는 struct 중에서 그 내부의 필드까지도 "non-nullable value type"이어야만 합니다.

---

unmanaged의 이러한 특성 덕분에 따라오는 struct와의 또 다른 차이점은, 바로 포인터 형을 정의할 수 있다는 것입니다.

class CallGenerics
{
    public static unsafe void AcceptBlittablePtr<T>(T *item) where T : unmanaged
    {
        Console.WriteLine(*item);
    }

    // 컴파일 에러 - Error CS0208 Cannot take the address of, get the size of, or declare a pointer to a managed type ('T')
    // public static unsafe void AcceptStructPtr<T>(T* item) where T : struct
    // {
    // }
}

struct BlittableStructType
{
    public int Age;
}

class Program
{
    static unsafe void Main()
    {
        BlittableStructType* pbst = &bst;
        CallGenerics.AcceptBlittablePtr<BlittableStructType>(pbst);
    }
}

위의 코드를 달리 해석하면, 다음과 같이 포인터로 형변환할 수 있는 타입만을 필요로 할 때 unmanaged 제약을 쓸 수 있다는 것이 됩니다.

using System;

namespace ConsoleApp1
{
    struct BlittableStructType
    {
        public int Age;
    }

    class Program
    {
        static void Main(string[] args)
        {
            BlittableStructType bst = new BlittableStructType();
            bst.Age = 500;

            Convert(bst);
        }

        static unsafe void Convert<T>(T value) where T : unmanaged
        {
            T* ptr = &value;
            IntPtr ptrAddress = new IntPtr(ptr);
            Console.WriteLine(ptrAddress.ToString("x"));
        }
    }
}

예약어 정의에 대한 미적 감각을 제외하고 unmanaged를 다른 예약어로 쉽게 정의해 본다면 "pointable_struct_type" 제약 정도가 될 것입니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)

---

[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]

[최초 등록일: 6/24/2018]
[최종 수정일: 6/25/2018]


이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

by SeongTae Jeong, mailto:techsharer at outlook.com