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

비밀번호

댓글 작성자
 



2025-03-30 12시19분
정성태

... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...
NoWriterDateCnt.TitleFile(s)
536정성태9/12/200732367.NET Framework: 97. WCF : netTcpBinding에서의 각종 Timeout 값 설명 [11]
535정성태9/11/200729825.NET Framework: 96. WCF - PerSession에서의 클라이언트 연결 관리 [5]
534정성태9/3/200725322개발 환경 구성: 29. VHD 파일 크기 줄이기
533정성태9/2/200728035개발 환경 구성: 28. CA 서비스 - 사용자 정의 템플릿 유형 추가
532정성태9/2/200730563개발 환경 구성: 27. AD CA에서 Code Signing 인증서 유형 추가 방법
531정성태9/2/200726323.NET Framework: 95. WCF에서의 DataTable 사용
530정성태9/1/200722872.NET Framework: 94. WCF 예외에 대한 시행착오
529정성태8/31/200725730.NET Framework: 93. WCF - DataContract와 KnownType 특성 [1]
528정성태8/30/200720381오류 유형: 47. VPC - 네트워크 어댑터 MAC 주소 중복 오류
527정성태8/30/200730447Team Foundation Server: 20. 잠긴 파일을 강제로 해제 [2]
526정성태8/29/200720354오류 유형: 46. VS.NET 2008 - ASP.NET 디버깅 : Strong name validation failed.
525정성태8/27/200722592VS.NET IDE: 54. VS.NET 2008 - 새롭게 도입되는 XSD Schema Designer
524정성태8/23/200740093오류 유형: 45. 요청한 작업은, 사용자가 매핑한 구역이 열려 있는...
523정성태8/16/200722795VS.NET IDE: 53. VS.NET 2008 - 서비스 참조 시 기존 데이터 컨테이너 DLL 사용
522정성태8/13/200726394VS.NET IDE: 52. VS.NET 2008 - WCF를 위한 디버깅 환경 개선
521정성태8/8/200726386.NET Framework: 92. XmlSerializer 생성자의 실행 속도를 올리는 방법 - 두 번째 이야기 [3]
520정성태8/7/200721599VS.NET IDE: 51. Visual Studio 2008 베타 2 설치
519정성태7/27/200727979오류 유형: 44. System.BadImageFormatException [2]
518정성태7/26/200728997오류 유형: 43. System.ComponentModel.LicenseException [1]
517정성태7/19/200717341개발 환경 구성: 26. VPC - 일반 사용자 계정으로 구동
516정성태7/19/200720473오류 유형: 42. TFS - Error loading menu: Index was outside the bounds of the array [2]
515정성태7/18/200728165오류 유형: 41. SSL 서버 자격 증명을 만드는 동안 심각한 오류가 발생했습니다.
514정성태7/14/200720862Team Foundation Server: 19. Orcas에서 개선되는 TFS 기능들
513정성태7/4/200731830.NET Framework: 91. Foreground Thread / Background Thread [1]
512정성태6/27/200721736오류 유형: 40. error PRJ0050: Failed to register output.
511정성태6/25/200729780.NET Framework: 90. XmlSerializer 생성자의 실행 속도를 올리는 방법 [2]
... 166  167  168  169  170  171  172  173  174  175  176  177  [178]  179  180  ...