Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)
(시리즈 글이 18개 있습니다.)
.NET Framework: 1110. C# 11 - 인터페이스 내에 정적 추상 메서드 정의 가능 (DIM for Static Members)
; https://www.sysnet.pe.kr/2/0/12814

.NET Framework: 1118. C# 11 - 제네릭 타입의 특성 적용
; https://www.sysnet.pe.kr/2/0/12839

.NET Framework: 1182. C# 11  - ref struct에 ref 필드를 허용
; https://www.sysnet.pe.kr/2/0/13015

.NET Framework: 2025. C# 11  - 원시 문자열 리터럴(raw string literals)
; https://www.sysnet.pe.kr/2/0/13085

.NET Framework: 2026. C# 11 - 문자열 보간 개선 2가지
; https://www.sysnet.pe.kr/2/0/13086

.NET Framework: 2030. C# 11 - UTF-8 문자열 리터럴
; https://www.sysnet.pe.kr/2/0/13096

.NET Framework: 2031. C# 11 - 사용자 정의 checked 연산자
; https://www.sysnet.pe.kr/2/0/13099

.NET Framework: 2032. C# 11 - shift 연산자 재정의에 대한 제약 완화 (Relaxing Shift Operator)
; https://www.sysnet.pe.kr/2/0/13100

.NET Framework: 2035. C# 11 - 새로운 연산자 ">>>" (Unsigned Right Shift)
; https://www.sysnet.pe.kr/2/0/13110

.NET Framework: 2036. C# 11 - IntPtr/UIntPtr과 nint/nuint의 통합
; https://www.sysnet.pe.kr/2/0/13111

.NET Framework: 2037. C# 11 - 목록 패턴(List patterns)
; https://www.sysnet.pe.kr/2/0/13112

.NET Framework: 2038. C# 11 - Span 타입에 대한 패턴 매칭 (Pattern matching on ReadOnlySpan<char>)
; https://www.sysnet.pe.kr/2/0/13113

.NET Framework: 2042. C# 11 - 파일 범위 내에서 유효한 타입 정의 (File-local types)
; https://www.sysnet.pe.kr/2/0/13117

.NET Framework: 2045. C# 11 - 메서드 매개 변수에 대한 nameof 지원
; https://www.sysnet.pe.kr/2/0/13122

.NET Framework: 2046. C# 11 - 멤버(속성/필드)에 지정할 수 있는 required 예약어 추가
; https://www.sysnet.pe.kr/2/0/13123

.NET Framework: 2048. C# 11 - 구조체 필드의 자동 초기화(auto-default structs)
; https://www.sysnet.pe.kr/2/0/13125

.NET Framework: 2049. C# 11 - 정적 메서드에 대한 delegate 처리 시 cache 적용
; https://www.sysnet.pe.kr/2/0/13126

.NET Framework: 2102. C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어
; https://www.sysnet.pe.kr/2/0/13276




C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어

C# 11 문법에 대해 모두 정리를 했었는데, 아래의 글을 보고 나서야,

C# 11-범위 지정 키워드
; https://forum.dotnetdev.kr/t/c-11-bart-wullems/6166

scoped 예약어의 존재를 알게 되었습니다. ^^ 그래서 뒤늦게나마 이렇게 정리를 하는 것이니, 기존 C# 11 글만 보신 분은 가볍게라도 한번 읽어보시길 권장합니다.




지난 글에서 ref struct의 생성자에 ref 인자로 받는 경우 그 인스턴스를 반환한다면 무조건 오류가 발생한다고 했습니다.

GetData();

static MyType GetData()
{
    int n = 5;
    var t = new MyType(ref n);
    return t; // 컴파일 오류 - error CS8352: Cannot use variable 't' in this context because it may expose referenced variables outside of their declaration scope
}

// 외부 어셈블리에서 정의했을 지도 모를 MyType의 생성자 구현이 어떻게 되어 있는지 알 수 없으므로!
// 1. 만약 이렇게 구현되었다면 문제가 없지만,
ref struct MyType
{
    public MyType(ref int n1) { }
}

// 2. 이렇게 구현되었다면 문제가 될 수 있음.
/*
ref struct MyType
{
    ref int n;

    public MyType(ref int n1) { n = ref n1; }
}
*/

바로 이런 경우, MyType의 생성자에 넘겨 준 ref 변수가 어떤 식으로든 생성자 이외의 스택 범위로 전달하지 않겠다는 표시를 scoped 예약어로 지정할 수 있습니다. 그래서 다음과 같이 코드를 추가하면,

GetData();

static MyType GetData()
{
    int n = 5;
    var t = new MyType(ref n);
    return t; // 정상 컴파일
}

ref struct MyType
{
    public MyType(scoped ref int n1)
    {
    }
}

다시 이전의 예제가 정상적으로 컴파일 됩니다. 실제로 저렇게 scoped를 적용하게 되면, 해당 메서드는 ref int 매개변수의 사용을 현재의 스택 프레임으로 막아버립니다.

ref struct MyType
{
    public ref int n;

    public MyType(scoped ref int n1)
    {
        n = ref n1; // 컴파일 오류 - "error CS8374: Cannot ref-assign 'n1' to 'n' because 'n1' has a narrower escape scope than 'n'."
    }
}

따라서, MyType을 사용하는 측의 코드를 컴파일하는 입장에서는 해당 메서드에 "scoped"가 적용된 것만으로 안전하게 scope 판단을 할 수 있게 된 것입니다.

이 정도면 scoped 예약어의 느낌이 팍 오시죠? ^^




또 다른 사례를 하나 볼까요? ^^

C# 11–The scoped keyword
; https://bartwullems.blogspot.com/2023/02/c-11the-scoped-keyword.html

위의 글에 소개된 예제 코드를 간단하게 축약하면 다음과 같은 코드로 재현할 수 있습니다.

MyType instance = new MyType();
Process(instance);

static void Process(MyType data)
{
    Span<int> values = stackalloc int[10];

    data.Convert(values); // 컴파일 오류 2개
        // error CS8352: Cannot use variable 'values' in this context because it may expose referenced variables outside of their declaration scope
        // error CS8350: This combination of arguments to 'MyType.Convert(Span)' is disallowed because it may expose variables referenced by parameter 'values' outside of their declaration scope

}

ref struct MyType
{
    public void Convert(Span<int> values) { }
}

일면 이해가 됩니다. "data.Convert(values)" 코드를 컴파일하는 입장에서 MyType의 Convert 메서드 구현이 어떻게 되었을지 모르므로 이번에도 역시 "it may expose"로 오류를 내고 있습니다. 사실, 위의 코드상으로는 문제가 없지만, 만약 MyType이 외부 어셈블리에 다음과 같이 구현되었다면,

ref struct MyType
{
    Span<int> _values;
    public void Convert(Span<int> values) { _values = values; }
}

문제가 발생할 수 있습니다. 이런 경우에도 역시, Convert에 scoped 제약을 주면,

ref struct MyType
{
    public void Convert(scoped Span<int> values) { }
}

Convert 메서드를 호출하는 측의 코드를 처리하는 C# 컴파일러 입장에서는 "scoped"가 적용된 메서드에 전달하는 매개변수의 사용 범위를 계산할 수 있으므로 컴파일 오류 없이 진행할 수 있습니다. 게다가 실제로 scoped가 있는 상태에서는,

ref struct MyType
{
    Span<int> _values;
    public void Convert(scoped Span<int> values) { _values = values; } // 컴파일 에러 - error CS8352: Cannot use variable 'Span' in this context because it may expose referenced variables outside of their declaration scope
}

이렇게, ^^ 감히 범위를 넘어서려는 시도는 컴파일 에러를 발생시키기 때문에 scoped를 믿고 의지할 수 있습니다.




위의 Span 예제 코드를 Span 대신 다음과 같이 일반적인 ref struct로 대체해 재현하는 것도 가능합니다.

MyType instance = new MyType();
Process(instance);

static void Process(MyType data)
{
    int n = 5;
    IntRef refN = new IntRef(ref n);

    data.Convert(refN); // 컴파일 오류 2개
                // error CS8352: Cannot use variable 'values' in this context because it may expose referenced variables outside of their declaration scope
                // error CS8350: This combination of arguments to 'MyType.Convert(Span)' is disallowed because it may expose variables referenced by parameter 'values' outside of their declaration scope
}

ref struct MyType
{
    IntRef _ref;
    public void Convert(IntRef refVar) { _ref = refVar; }
    // 아래의 코드로 바꾸면 컴파일 없이 진행
    // public void Convert(scoped IntRef refVar) { }
}

ref struct IntRef
{
    public ref int n;
    public IntRef(ref int n1) { n = ref n1; }
}

차근차근 코드를 뜯어보시면 Span 예제와 다를 바가 없고, 왜 오류 처리를 해야만 하는지, scoped로 바꾸면 왜 괜찮은 것인지 알 수 있을 것입니다. ^^




자, 이제부턴 ^^ 딴지를 좀 걸어볼까요?

위에서 계속 다룬 예제 코드는 내부의 변수를 외부에서 접근할 수 있는 문제가 있어 그걸 막기 위해 C# 컴파일러가 분주하게 유효성 체크를 한 것입니다. 그런데, 좀 이상하지 않나요? 위에서 다룬 "MyType"은 분명히 ref struct로 값 형식입니다. 따라서 instance 변수를 Process 메서드에 전달한다고 해도 "값 복사"가 되므로 매개변수인 data에 대해 Convert 메서드를 호출한다고 해도 외부 인스턴스에 영향을 미치지 못합니다.

위의 코드가 메서드 호출이라서 헷갈릴 수 있지만, 다음과 같이 로컬 변수로 테스트하면,

int n = 10;
ref int n1 = ref n; // 외부 ref struct의 ref 필드에 보관한 것으로 가정

ref int n2 = ref n1; // 외부 ref struct를 메서드의 인자로 전달한 것으로 가정

int k = 60;
n2 = ref k; // 메서드의 매개변수에 대해 새롭게 ref를 지정해도,
Console.WriteLine(n1); // 출력: 10, 즉 매개변수의 변경으로 외부 ref struct의 ref 필드가 변경되는 것은 아님.

지금까지의 예제에서 Process 메서드에 전달한 data 타입이 외부의 instance 변수에 아무런 영향을 끼칠 수 없다는 것을 알 수 있을 것입니다. 만약, 영향을 끼치려면 Process 메서드에 대해 다음과 같이 ref로 처리를 해야 합니다.

MyType instance = new MyType();
Process(ref instance); // 이렇게 전달해야만,

static void Process(ref MyType data) // Process 메서드 내부에서 data에 설정한 값이 외부 스택 프레임으로 전달할 수 있게 됨!
{
    int n = 5;
    IntRef refN = new IntRef(ref n);

    data.Convert(refN); // 컴파일 오류 2개
}

C# 컴파일러가 제대로 구분하지 못하는 또 다른 경우가 있는데요, 심지어 외부 변수를 전달하지 않는 경우에도 여전히 컴파일 오류가 발생합니다.

Process();

static void Process()
{
    int n = 5;
    
    IntRef refN = new IntRef(ref n);

    MyType data = new MyType();
    data.Convert(refN); // 컴파일 오류 2개
}

// MyType, IntRef 생략

보는 바와 같이, 이번에는 MyType data와 IntRef refN 변수가 Process 메서드의 스택 프레임 내에 함께 존재하므로 이런 경우에도 C# 컴파일러의 오류가 발생할 필요는 없습니다. 이런 부분을 향후 C# 컴파일러에서는 개선을 할지, 아니면 제가 모르는 다른 경우의 수가 있는 것인지는 모르겠습니다. ^^




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/5/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)
13294정성태3/22/20234122.NET Framework: 2105. LargeAddressAware 옵션이 적용된 닷넷 32비트 프로세스의 가용 메모리 - 두 번째
13293정성태3/22/20234191오류 유형: 853. dumpbin - warning LNK4048: Invalid format file; ignored
13292정성태3/21/20234305Windows: 232. C/C++ - 일반 창에도 사용 가능한 IsDialogMessage파일 다운로드1
13291정성태3/20/20234712.NET Framework: 2104. C# Windows Forms - WndProc 재정의와 IMessageFilter 사용 시의 차이점
13290정성태3/19/20234219.NET Framework: 2103. C# - 윈도우에서 기본 제공하는 FindText 대화창 사용법파일 다운로드1
13289정성태3/18/20233416Windows: 231. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 자식 윈도우를 생성하는 방법파일 다운로드1
13288정성태3/17/20233515Windows: 230. Win32 - 대화창의 DLU 단위를 pixel로 변경하는 방법파일 다운로드1
13287정성태3/16/20233683Windows: 229. Win32 - 대화창 템플릿의 2진 리소스를 읽어들여 윈도우를 직접 띄우는 방법파일 다운로드1
13286정성태3/15/20234146Windows: 228. Win32 - 리소스에 포함된 대화창 Template의 2진 코드 해석 방법
13285정성태3/14/20233737Windows: 227. Win32 C/C++ - Dialog Procedure를 재정의하는 방법파일 다운로드1
13284정성태3/13/20233937Windows: 226. Win32 C/C++ - Dialog에서 값을 반환하는 방법파일 다운로드1
13283정성태3/12/20233478오류 유형: 852. 파이썬 - TypeError: coercing to Unicode: need string or buffer, NoneType found
13282정성태3/12/20233807Linux: 58. WSL - nohup 옵션이 필요한 경우
13281정성태3/12/20233716Windows: 225. 윈도우 바탕화면의 아이콘들이 넓게 퍼지는 경우 [2]
13280정성태3/9/20234453개발 환경 구성: 670. WSL 2에서 호스팅 중인 TCP 서버를 외부에서 접근하는 방법
13279정성태3/9/20233997오류 유형: 851. 파이썬 ModuleNotFoundError: No module named '_cffi_backend'
13278정성태3/8/20233945개발 환경 구성: 669. WSL 2의 (init이 아닌) systemd 지원 [1]
13277정성태3/6/20234576개발 환경 구성: 668. 코드 사인용 인증서 신청 및 적용 방법(예: Digicert)
13276정성태3/5/20234306.NET Framework: 2102. C# 11 - ref struct/ref field를 위해 새롭게 도입된 scoped 예약어
13275정성태3/3/20234660.NET Framework: 2101. C# 11의 ref 필드 설명
13274정성태3/2/20234252.NET Framework: 2100. C# - ref 필드로 ref struct 타입을 허용하지 않는 이유
13273정성태2/28/20233953.NET Framework: 2099. C# - 관리 포인터로서의 ref 예약어 의미
13272정성태2/27/20234202오류 유형: 850. SSMS - mdf 파일을 Attach 시킬 때 Operating system error 5: "5(Access is denied.)" 에러
13271정성태2/25/20234142오류 유형: 849. Sql Server Configuration Manager가 시작 메뉴에 없는 경우
13270정성태2/24/20233754.NET Framework: 2098. dotnet build에 /p 옵션을 적용 시 유의점
13269정성태2/23/20234290스크립트: 46. 파이썬 - uvicorn의 콘솔 출력을 UDP로 전송
1  2  3  4  5  6  7  8  9  10  11  12  [13]  14  15  ...