Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 

(시리즈 글이 6개 있습니다.)
.NET Framework: 754. 닷넷의 관리 포인터(Managed Pointer)와 System.TypedReference
; https://www.sysnet.pe.kr/2/0/11529

.NET Framework: 1183. C# 11에 추가된 ref 필드의 (우회) 구현 방법
; https://www.sysnet.pe.kr/2/0/13016

.NET Framework: 2099. C# - 관리 포인터로서의 ref 예약어 의미
; https://www.sysnet.pe.kr/2/0/13273

.NET Framework: 2100. C# - ref 필드로 ref struct 타입을 허용하지 않는 이유
; https://www.sysnet.pe.kr/2/0/13274

.NET Framework: 2101. C# 11의 ref 필드 설명
; https://www.sysnet.pe.kr/2/0/13275

닷넷: 2327. C# - 초기화되지 않은 메모리에 접근하는 버그?
; https://www.sysnet.pe.kr/2/0/13906




C# - ref 필드로 ref struct 타입을 허용하지 않는 이유

지난 글에서 관리 포인터를 알아봤는데요,

C# - 관리 포인터로서의 ref 예약어 의미
; https://www.sysnet.pe.kr/2/0/13273

관리 포인터는 GC 성능 문제로 인해 GC Heap 내에 필드로 존재할 수 없습니다. 그래서 class나 struct의 필드로는,

class MyClass
{
    public ref int N; // 컴파일 에러: error CS9059: A ref field can only be declared in a ref struct.
}

struct MyStruct
{
    public ref int N; // 컴파일 에러: error CS9059: A ref field can only be declared in a ref struct.
}

ref 유형을 정의할 수 없습니다. class는 당연히 GC Heap에 생성되므로 안 되고, struct의 경우에는 메서드 내에서 사용하는 경우라면 스택에 있겠지만 class의 필드로 포함되면 역시 GC Heap에 생성되므로 안 되는 것입니다.

그래서, 결국 (C# 7.2부터 지원하는) ref struct에서만 ref 필드를 가질 수 있게 되는데요,

ref struct MyRefStruct
{
    public ref int N;
}

재미있는 것은, 오직 GC Heap에 있는 인스턴스만을 저 ref 필드에 대입할 수 있다는 점입니다. 예를 들어 볼까요?

internal class Program
{
    static void Main(string[] args)
    {
        int n = 5;
        MyRefStruct data = new MyRefStruct();

        data.N = ref n; // 컴파일 오류: error CS8374: Cannot ref-assign 'n' to 'N' because 'n' has a narrower escape scope than 'N'.
                        // error CS8374: 'n'을(를) 'N'에 참조 할당할 수 없습니다. 'n'이(가) 'N'보다 이스케이프 범위가 좁기 때문입니다.

        MyStruct ms = new MyStruct();
        data.N = ref ms.n; // 컴파일 오류: error CS8374: Cannot ref-assign 'n' to 'N' because 'n' has a narrower escape scope than 'N'.

        Program pg = new Program();
        data.N = ref pg.n; // 컴파일 정상
    }
}

ref struct MyRefStruct
{
    public ref int N;
}

public struct MyStruct
{
    public int n;
}

같은 메서드 내에서 정의했기 때문에 변수 n과 변수 data는 동일한 스택 프레임 위에 있는데도 불구하고 오류 메시지에서는 n이 data.N보다 해제가 더 빠르게 된다는 식으로 지적하고 있습니다. 또한 메서드 내에서 생성한 MyStruct 인스턴스도 스택에 있으므로 data.N에 대입을 못 시킵니다.

반면, 같은 int n이지만, class에 속해 있는 경우라면 data.N에 ref를 저장하고 있습니다.

그런데 사실, 위와 같은 코드라면 "C# - 관리 포인터로서의 ref 예약어 의미" 예제로 설명한 스택 범위에서의 문제가 발생하지 않습니다. (물론 그 예제에서처럼 return을 하면 문제가 됩니다.) 단지 저렇게 무조건 스택 변수를 받지 못하게 한 것은 다소 보수적인 입장으로 막은 것이 아닌가... 하는 추측입니다.

좀 더 따지고 보면, 이해할 수 없는 비교 코드가 하나 있긴 합니다.

int n = 5;

ref int N = ref n; // 컴파일 정상

MyRefStruct data = new MyRefStruct();
data.N = ref n; // 컴파일 오류

ref int도 같은 스택 프레임에 있고, 어차피 data.N도 같은 입장인데 왜? ref struct에 대해서만 저렇게 엄격한 escape 판단을 적용하는지 알 수 없습니다.




다소 특이하다고 생각할 수 있는데, ref 필드는 그 타입으로 ref struct 형식을 허용하지 않습니다.

ref struct MyRefData
{
}

ref struct MyRefStruct
{
    public ref int N;

    public ref MyRefData Data; // 컴파일 오류: error CS9050: A ref field cannot refer to a ref struct.
}

int도 값 형식이고, MyRefData도 값 형식인데 왜? ref struct에 대해서만 막은 것일까요?

사실, 그 이유를 이번 글의 내용을 숙지하셨다면 짐작할 수 있을 것입니다. 그러니까, int 값 형식도 스택에서 정의된 경우에는 ref 필드로 참조를 가질 수 없도록 C# 컴파일러가 막고 있었는데요, 그렇다면 항상 스택에만 생성되는 ref struct에 대해서는 당연히 C# 컴파일러가 막는 것이 맞습니다.

그런 이유로 결국, ref struct 내에는 ref Span 필드를 가질 수 없습니다.

public ref struct MyRefStruct
{
    public ref Span<int> data; // Span<T>는 ref struct이므로 컴파일 오류: error CS9050: A ref field cannot refer to a ref struct.
}




그나저나, ref 필드에 대입하는 필드가 스택인지 힙인지 알 수 없는 경우도 있습니다. 이에 대한 예제 코드를 이렇게 구성할 수 있는데요,

internal class Program
{
    int n;

    static void Main(string[] args)
    {
        int n = 5;
        Process(ref n); // 스택으로부터
        Process2(ref n);

        Program pg = new Program();
        Process(ref pg.n); // 힙으로부터
        Process2(ref pg.n);
    }

    static void Process(ref int n)
    {
        ref int temp = ref n; // 컴파일 정상

        MyRefStruct msf = new MyRefStruct();
        msf.N = ref n; // 컴파일 오류: error CS9079: Cannot ref-assign 'n' to 'N' because 'n' can only escape the current method through a return statement.
                       // error CS9079: 'n'은(는) return 문을 통해서만 현재 메서드를 이스케이프할 수 있으므로 'n'을(를) 'N'에 다시 할당할 수 없습니다.
    }

    static void Process2(ref int n)
    {
        MyRefStruct data = new MyRefStruct(ref n); // 컴파일 정상
    }
}

public ref struct MyRefStruct
{
    public ref int N;

    public MyRefStruct(ref int n)
    {
        N = ref n;
    }
}

위의 코드도 엄밀히 따지면 "ref int temp = ref n;" 코드가 정상 동작하는 것처럼 "msf.N = ref n;" 코드도 문제가 없을 상황입니다. 왜냐하면 메서드의 인자로 전달받은 것은 그것이 스택이든 힙이든지에 상관없이 메서드가 가진 스택 프레임의 바깥에 위치하기 때문에 ref struct 인스턴스가 살아 있는 범위를 넘어섰으므로 유효합니다. (저 코드에서 발생하는 컴파일 오류 메시지의 내용이 원인을 잘 설명하지도 못 하는 것 같습니다.)

이러한 차이점에 대한 해석을 억지로 해보자면, 전자의 코드는 하위 호환성을 위해 그냥 허용하고 ref struct부터 원래 적용했어야 할 기준을 설정한 것이 아닐까... 혹은 아직 ref field에 대한 C# 컴파일러의 유효성 체크를 더 다듬어야 하지 않을까... 라는 추측만 해봅니다. ^^ (혹시 정확한 차이점을 알고 계신 분은 덧글 부탁드립니다.)




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







[최초 등록일: ]
[최종 수정일: 5/4/2023]

Creative Commons License
이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.
by SeongTae Jeong, mailto:techsharer at outlook.com

비밀번호

댓글 작성자
 




1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13818정성태11/15/20245240Windows: 272. Windows 11 24H2 - sudo 추가
13817정성태11/14/20244909Linux: 106. eBPF / bpf2go - (BPF_MAP_TYPE_HASH) Map을 이용한 전역 변수 구현
13816정성태11/14/20245371닷넷: 2312. C#, C++ - Windows / Linux 환경의 Thread Name 설정파일 다운로드1
13815정성태11/13/20244793Linux: 105. eBPF - bpf2go에서 전역 변수 설정 방법
13814정성태11/13/20245276닷넷: 2311. C# - Windows / Linux 환경에서 Native Thread ID 가져오기파일 다운로드1
13813정성태11/12/20245013닷넷: 2310. .NET의 Rune 타입과 emoji 표현파일 다운로드1
13812정성태11/11/20245243오류 유형: 933. Active Directory - The forest functional level is not supported.
13811정성태11/11/20244835Linux: 104. Linux - COLUMNS 환경변수가 언제나 80으로 설정되는 환경
13810정성태11/10/20245363Linux: 103. eBPF (bpf2go) - Tracepoint를 이용한 트레이스 (BPF_PROG_TYPE_TRACEPOINT)
13809정성태11/10/20245249Windows: 271. 윈도우 서버 2025 마이그레이션
13808정성태11/9/20245240오류 유형: 932. Linux - 커널 업그레이드 후 "error: bad shim signature" 오류 발생
13807정성태11/9/20244980Linux: 102. Linux - 커널 이미지 파일 서명 (Ubuntu 환경)
13806정성태11/8/20244885Windows: 270. 어댑터 상세 정보(Network Connection Details) 창의 내용이 비어 있는 경우
13805정성태11/8/20244721오류 유형: 931. Active Directory의 adprep 또는 복제가 안 되는 경우
13804정성태11/7/20245352Linux: 101. eBPF 함수의 인자를 다루는 방법
13803정성태11/7/20245304닷넷: 2309. C# - .NET Core에서 바뀐 DateTime.Ticks의 정밀도
13802정성태11/6/20245677Windows: 269. GetSystemTimeAsFileTime과 GetSystemTimePreciseAsFileTime의 차이점파일 다운로드1
13801정성태11/5/20245469Linux: 100. eBPF의 2가지 방식 - libbcc와 libbpf(CO-RE)
13800정성태11/3/20246305닷넷: 2308. C# - ICU 라이브러리를 활용한 문자열의 대소문자 변환 [2]파일 다운로드1
13799정성태11/2/20244891개발 환경 구성: 732. 모바일 웹 브라우저에서 유니코드 문자가 표시되지 않는 경우
13798정성태11/2/20245490개발 환경 구성: 731. 유니코드 - 출력 예시 및 폰트 찾기
13797정성태11/1/20245478C/C++: 185. C++ - 문자열의 대소문자를 변환하는 transform + std::tolower/toupper 방식의 문제점파일 다운로드1
13796정성태10/31/20245363C/C++: 184. C++ - ICU dll을 이용하는 예제 코드 (Windows)파일 다운로드1
13795정성태10/31/20245150Windows: 268. Windows - 리눅스 환경처럼 공백으로 끝나는 프롬프트 만들기
13794정성태10/30/20245261닷넷: 2307. C# - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
13793정성태10/28/20245123C/C++: 183. C++ - 윈도우에서 한글(및 유니코드)을 포함한 콘솔 프로그램을 컴파일 및 실행하는 방법
1  2  3  4  [5]  6  7  8  9  10  11  12  13  14  15  ...