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

비밀번호

댓글 작성자
 




... 61  62  63  64  [65]  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12315정성태9/7/202019842개발 환경 구성: 510. Logstash - FileBeat을 이용한 IIS 로그 처리 [2]
12314정성태9/7/202020058오류 유형: 645. IIS HTTPERR - Timer_MinBytesPerSecond, Timer_ConnectionIdle 로그
12313정성태9/6/202019555개발 환경 구성: 509. Logstash - 사용자 정의 grok 패턴 추가를 이용한 IIS 로그 처리
12312정성태9/5/202026507개발 환경 구성: 508. Logstash 기본 사용법 [2]
12311정성태9/4/202019105.NET Framework: 937. C# - 간단하게 만들어 보는 리눅스의 nc(netcat), json_pp 프로그램 [1]
12310정성태9/3/202018417오류 유형: 644. Windows could not start the Elasticsearch 7.9.0 (elasticsearch-service-x64) service on Local Computer.
12309정성태9/3/202017591개발 환경 구성: 507. Elasticsearch 6.6부터 기본 추가된 한글 형태소 분석기 노리(nori) 사용법
12308정성태9/2/202019460개발 환경 구성: 506. Windows - 단일 머신에서 단일 바이너리로 여러 개의 ElasticSearch 노드를 실행하는 방법
12307정성태9/2/202020344오류 유형: 643. curl - json_parse_exception / Invalid UTF-8 start byte
12306정성태9/1/202017588오류 유형: 642. SQL Server 시작 오류 - error code 10013
12305정성태9/1/202019450Windows: 172. "Administered port exclusions"이 아닌 포트 범위 항목을 삭제하는 방법
12304정성태8/31/202017903개발 환경 구성: 505. 윈도우 - (네트워크 어댑터의 우선순위로 인한) 열거되는 IP 주소 순서를 조정하는 방법
12303정성태8/30/202018173개발 환경 구성: 504. ETW - 닷넷 프레임워크 기반의 응용 프로그램을 위한 명령행 도구 etrace 소개
12302정성태8/30/202018331.NET Framework: 936. C# - ETW 관련 Win32 API 사용 예제 코드 (5) - Private Logger파일 다운로드1
12301정성태8/30/202017873오류 유형: 641. error MSB4044: The "Fody.WeavingTask" task was not given a value for the required parameter "IntermediateDir".
12300정성태8/29/202018239.NET Framework: 935. C# - ETW 관련 Win32 API 사용 예제 코드 (4) CLR ETW Consumer파일 다운로드1
12299정성태8/27/202018867.NET Framework: 934. C# - ETW 관련 Win32 API 사용 예제 코드 (3) ETW Consumer 구현파일 다운로드1
12298정성태8/27/202018425오류 유형: 640. livekd - Could not resolve symbols for ntoskrnl.exe: MmPfnDatabase
12297정성태8/25/202017945개발 환경 구성: 503. SHA256 테스트 인증서 생성 방법
12296정성태8/24/202019109.NET Framework: 933. C# - ETW 관련 Win32 API 사용 예제 코드 (2) NT Kernel Logger파일 다운로드1
12295정성태8/24/202017939오류 유형: 639. Bitvise - Address is already in use; bind() in ListeningSocket::StartListening() failed: Windows error 10013: An attempt was made to access a socket ,,,
12293정성태8/24/202018897Windows: 171. "Administered port exclusions" 설명
12292정성태8/20/202021858.NET Framework: 932. C# - ETW 관련 Win32 API 사용 예제 코드 (1)파일 다운로드2
12291정성태8/15/202018790오류 유형: 638. error 1297: Device driver does not install on any devices, use primitive driver if this is intended.
12290정성태8/11/202020067.NET Framework: 931. C# - IP 주소에 따른 국가별 위치 확인 [8]파일 다운로드1
12289정성태8/6/202017010개발 환경 구성: 502. Portainer에 윈도우 컨테이너를 등록하는 방법
... 61  62  63  64  [65]  66  67  68  69  70  71  72  73  74  75  ...