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)
13589정성태3/29/20244838닷넷: 2233. C# - 프로세스 CPU 사용량을 나타내는 성능 카운터와 Win32 API파일 다운로드1
13588정성태3/28/20245430닷넷: 2232. C# - Unity + 닷넷 App(WinForms/WPF) 간의 Named Pipe 통신 [2]파일 다운로드1
13587정성태3/27/20244765오류 유형: 900. Windows Update 오류 - 8024402C, 80070643
13586정성태3/27/20246722Windows: 263. Windows - 복구 파티션(Recovery Partition) 용량을 늘리는 방법
13585정성태3/26/20245151Windows: 262. PerformanceCounter의 InstanceName에 pid를 추가한 "Process V2"
13584정성태3/26/20245539개발 환경 구성: 708. Unity3D - C# Windows Forms / WPF Application에 통합하는 방법 [4]파일 다운로드1
13583정성태3/25/20245084Windows: 261. CPU Utilization이 100% 넘는 경우를 성능 카운터로 확인하는 방법
13582정성태3/19/20245402Windows: 260. CPU 사용률을 나타내는 2가지 수치 - 사용량(Usage)과 활용률(Utilization)파일 다운로드1
13581정성태3/18/20245388개발 환경 구성: 707. 빌드한 Unity3D 프로그램을 C++ Windows Application에 통합하는 방법
13580정성태3/15/20244738닷넷: 2231. C# - ReceiveTimeout, SendTimeout이 적용되지 않는 Socket await 비동기 호출파일 다운로드1
13579정성태3/13/20245352오류 유형: 899. HTTP Error 500.32 - ANCM Failed to Load dll
13578정성태3/11/20245826닷넷: 2230. C# - 덮어쓰기 가능한 환형 큐 (Circular queue)파일 다운로드1
13577정성태3/9/20245957닷넷: 2229. C# - 닷넷을 위한 난독화 도구 소개 (예: ConfuserEx)
13576정성태3/8/20245068닷넷: 2228. .NET Profiler - IMetaDataEmit2::DefineMethodSpec 사용법
13575정성태3/7/20245508닷넷: 2227. 최신 C# 문법을 .NET Framework 프로젝트에 쓸 수 있을까요?
13574정성태3/6/20245225닷넷: 2226. C# - "Docker Desktop for Windows" Container 환경에서의 IPv6 DualMode 소켓
13573정성태3/5/20244897닷넷: 2225. Windbg - dumasync로 분석하는 async/await 호출
13572정성태3/4/20245207닷넷: 2224. C# - WPF의 Dispatcher Queue로 알아보는 await 호출의 hang 현상파일 다운로드1
13571정성태3/1/20244933닷넷: 2223. C# - await 호출과 WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13570정성태2/29/20245060닷넷: 2222. C# - WPF의 Dispatcher Queue 동작 확인파일 다운로드1
13569정성태2/28/20244702닷넷: 2221. C# - LoadContext, LoadFromContext 그리고 GAC파일 다운로드1
13568정성태2/27/20244695닷넷: 2220. C# - .NET Framework 프로세스의 LoaderOptimization 설정을 확인하는 방법파일 다운로드1
13567정성태2/27/20244651오류 유형: 898. .NET Framework 3.5 이하에서 mscoree.tlb 참조 시 System.BadImageFormatException파일 다운로드1
13566정성태2/27/20244651오류 유형: 897. Windows 7 SDK 설치 시 ".NET Development" 옵션이 비활성으로 선택이 안 되는 경우
13565정성태2/23/20244619닷넷: 2219. .NET CLR2 보안 모델에서의 개별 System.Security.Permissions 제어
13564정성태2/22/20245022Windows: 259. Hyper-V Generation 1 유형의 VM을 Generation 2 유형으로 바꾸는 방법
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...