Microsoft MVP성태의 닷넷 이야기
.NET Framework: 751. C# 7.2 - 메서드의 매개 변수에 in 변경자 추가 [링크 복사], [링크+제목 복사]
조회: 16252
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 10개 있습니다.)

C# 7.2 - 메서드의 매개 변수에 in 변경자 추가

C# 7.2 (1) - readonly 구조체
; https://www.sysnet.pe.kr/2/0/11524

C# 7.2 (2) - 메서드의 매개 변수에 in 변경자 추가
; https://www.sysnet.pe.kr/2/0/11525

C# 7.2 (3) - 메서드의 반환값 및 로컬 변수에 ref readonly 기능 추가
; https://www.sysnet.pe.kr/2/0/11526

C# 7.2 (4) - 3항 연산자에 ref 지원(conditional ref operator)
; https://www.sysnet.pe.kr/2/0/11528

C# 7.2 (5) - 스택에만 생성할 수 있는 값 타입 지원 - "ref struct"
; https://www.sysnet.pe.kr/2/0/11530

C# 7.2 (6) - Span<T>
; https://www.sysnet.pe.kr/2/0/11534

C# 7.2 (7) - private protected 접근자 추가
; https://www.sysnet.pe.kr/2/0/11543

C# 7.2 (8) - 숫자 리터럴의 선행 밑줄과 뒤에 오지 않는 명명된 인수
; https://www.sysnet.pe.kr/2/0/11544

기타 - Microsoft Build 2018 - The future of C# 동영상 내용 정리
; https://www.sysnet.pe.kr/2/0/11536




알려진 바와 같이, 매개 변수를 위한 변경자는 ref만이 CLR 레벨에서 제공되고, out은 C# 언어 수준에서 확장한 것입니다.

  • ref: 매개 변수의 주소를 전달
  • out: ref 매개 변수이면서 출력 전용으로 C#에서 추가한 기능

즉, out 예약어는 ref 기능에 System.Runtime.InteropServices.OutAttribute 특성이 부여된 것이고 C# 컴파일러는 OutAttribute 특성이 있는 매개 변수에 대해서는 반드시 메서드가 사용 또는 반환하기 전 값을 설정하지 않으면 컴파일 오류를 발생시킵니다.

예를 들어 볼까요? ^^

using System;

class Program
{
    static void Main(string[] args)
    {
        int age = 5;

        Program pg = new Program();
        pg.Get(out age);
    }

    void Get(out int n)
    {
        Console.WriteLine(n); // CS0269 Use of unassigned out parameter 'n'
    }
}

위의 코드를 빌드하면 CS0269 컴파일 오류가 발생합니다. 왜냐하면 (ref이면서 OutAttribute 특성이 부여된) out 매개 변수의 값을 메서드 내에서 할당한 적 없이 사용하려고 했기 때문입니다. 그런데, out 매개 변수의 값이 정말로 "ref이면서 OutAttribute 특성이 부여된" 것에 불과하다면 실제로는 "int age = 5"에 의해 5라는 값이 설정되어 있을 것입니다. 이를 다음의 코드로 확인할 수 있습니다.

unsafe void Get(out int n)
{
    fixed(int* pN = &n)
    {
        Console.WriteLine(*pN); // 출력: 5
    }
}

n의 값에 어떠한 값도 넣지 않았지만 그 주소를 구해 값을 참조해 보면 메서드 호출 측에서 할당되었던 값이 나옵니다.




이와 유사하게, C# 7.2부터 추가된 "매개 변수의 in 예약어"도 ref 예약어의 변형에 불과합니다.

in : ref 매개 변수이면서 System.Runtime.CompilerServices.IsReadOnlyAttribute 특성을 부여

따라서 이것 역시 (CLR 레벨이 아닌) C# 컴파일러에 정해진 "읽기 전용"이라는 제약 사항을 갖습니다. 이것이 왜 유용한지 예제 코드를 통해 알아보겠습니다.

struct StructPerson
{
    public int Age;
    public string Name;
}

using System;
using System.Collections.Generic;
using System.Threading;

class Program
{
    unsafe static void Main(string[] args)
    {
        Program pg = new Program();

        StructPerson sarah = new StructPerson() { Name = "Kerrigan", Age = 27 };
        pg.StructParam(sarah); //  값 전달에 의해 내용 복사
    }

    void StructParam(StructPerson p)
    {
    }
}

StructParam 메서드의 경우, 값 형식의 매개 변수를 받기 때문에 p는 sarah 인스턴스의 모든 값이 복제되어 만들어진 값입니다. 따라서 메서드 내에서 값을 변경한다고 해도 호출 측의 sarah 인스턴스에 전혀 영향을 미치지 않습니다. 여기서 문제는, 복잡한 구조체의 경우 값을 모두 복사해야 하므로 그에 따른 부하가 클 수 있다는 것입니다.

이런 부하를 없애기 위해 StructPerson 매개 변수를 ref로 지정할 수 있습니다.

void StructParam(ref StructPerson p)
{
}

이제는 복사에 따른 부하가 없겠지만, 반대로 메서드 내에서 값을 변경하는 경우 호출 측의 인스턴스에 영향을 미치는 문제가 발생합니다. 그렇다면 복사에 따른 부하도 없으면서 호출 측의 인스턴스에 영향을 주지 않을 방법은 없을까요? 바로 이 문제를 해결하기 위해 in 예약어가 추가됩니다.

void StructParam(in StructPerson p)
{
}

앞에서 이야기했듯이, in 예약어는 ref의 하나입니다. 따라서 위의 메서드는 값 형식의 복사에 대한 부하가 없어집니다. 그러면서 IsReadOnly 특성이 부여되었으므로 C# 컴파일러는 해당 메서드 내에서 값이 변경되지 않을 거라는 보장을 해줍니다. 따라서 원래 in 예약어는 다음과 같은 기존 예약어의 구성으로 표현할 수 있습니다.

/*
문법적으로 허용되지는 않지만 기존 예약어들을 이용해 in 예약어를 수식하면 다음과 같은 의미가 됨.
*/
void StructParam(ref readonly StructPerson p)
{
    // 당연히 readonly이기 때문에 다음의 코드는 컴파일 오류 발생
    p.Age = 50;  //  CS8332 Cannot assign to a member of variable 'in StructPerson' because it is a readonly variable
}

/* 2023-10-25 업데이트: C# 12부터 in과 유사한 "ref readonly" 예약어가 추가됩니다. */

아무래도 메서드의 매개 변수를 수식하는 것이다 보니 기존 ref, out과 유사한 맥락에서 in으로 정한 것 같습니다.

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




in 매개 변수가 ref + readonly이기 때문에 readonly로 인한 모든 규칙을 그대로 포함합니다. 즉, 다음의 글에 설명했던 내용들이 in 매개 변수에도 똑같이 적용됩니다.

C# - 값 형식의 readonly 인스턴스에 대한 메서드 호출 시 defensive copy 발생
; https://www.sysnet.pe.kr/2/0/11523

이 때문에 in 매개 변수는 메서드 내에서 해당 인스턴스의 메서드/속성을 접근할 때 마찬가지로 "defensive copy"가 발생합니다. 그리고 이에 대한 부하를 줄이기 위해 나왔던 것이 바로 readonly 구조체입니다.

C# 7.2 - readonly 구조체
; https://www.sysnet.pe.kr/2/0/11524

따라서, in 매개 변수로 넘겨줄 구조체가 있다면 readonly 구조체로 만들어 주는 것이 좋습니다.




참고로, in 매개 변수를 표현하기 위해 추가된 System.Runtime.CompilerServices.IsReadOnlyAttribute 특성은 .NET Framework 4.7.1부터 추가되었습니다.

Announcing the .NET Framework 4.7.1
Compiler - Support for ReadOnlyReferences
; https://devblogs.microsoft.com/dotnet/announcing-the-net-framework-4-7-1/

그렇다면 in 매개 변수를 사용하기 위해 .NET Framework을 4.7.1 이상으로 사용해야 하는 걸까요? 똑똑하게도 ^^ C# 컴파일러는 그 이하의 .NET 버전을 대상으로 빌드하게 되면 해당 어셈블리에 다음의 코드를 함께 넣어 빌드해 주기 때문에 컴파일 오류가 발생하지 않습니다.

namespace System.Runtime.CompilerServices
{
    [CompilerGenerated, Embedded]
    internal sealed class IsReadOnlyAttribute : Attribute
    {
        // Methods
        public IsReadOnlyAttribute() { }
    }
}

돌이켜 보니, 이런 친절함이 아쉬웠던 기능이 하나 생각납니다. ^^

C# 5의 Caller Info를 .NET 4.5 미만의 응용 프로그램에 적용하는 방법
; https://www.sysnet.pe.kr/2/0/10890

CallerInfo의 경우 .NET 3.5 이하에서 사용하려면 CallerMemberNameAttribute, CallerFilePathAttribute, CallerLineNumberAttribute 특성을 정의해서 포함해야 했는데, 그때도 지금처럼 C# 컴파일러가 자동으로 해줬으면 좋았을 듯합니다. ^^




이번 글을 읽고, 다음의 영문 문서들을 보시면 제법 이해가 잘 되실 것입니다. ^^

Readonly references
; https://github.com/dotnet/csharplang/blob/master/proposals/csharp-7.2/readonly-ref.md

The 'in'-modifier and the readonly structs in C#
; https://devblogs.microsoft.com/premier-developer/the-in-modifier-and-the-readonly-structs-in-c/




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 10/25/2023]

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

비밀번호

댓글 작성자
 



2020-11-28 02시03분
[Guest] 큰길이의 string을 메소드 매개변수로 전달시에 in parameter로 전달한다면 의도된 바처럼 해당변수를 읽기전용 참조로 전달하여 성능향상이 가능할것으로 보이는데. 어차피 string은 불변타입이니 컴파일러 또는 JIT이 알아서 최적화하도록 in 없이 byValue로 전달하는 것이 나을까요?
[guest]
2020-11-28 06시21분
(string을 포함해) 참조 형식은 in으로 인한 성능 향상에는 아무런 혜택이 없습니다. 답변이 되었을까요? ^^
정성태
2020-11-30 11시40분
[Guest] string은 수정이 있기 전까지는 참조형식의 장점을 누릴 수 있다는 점을 간과한거 같습니다.
덕분에 string에 대해서 깊이 생각해 볼 수 있었습니다.
관련 내용을 생각해보면서 명확한 설명을 제시해 주는 스택오버풀로우 질답이 있어 링크해 봅니다.
https://stackoverflow.com/questions/10792603/how-are-strings-passed-in-net
감사합니다.
[guest]

... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...
NoWriterDateCnt.TitleFile(s)
12551정성태3/5/20217323오류 유형: 702. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly. (2)
12550정성태3/5/20217025오류 유형: 701. Live Share 1.0.3713.0 버전을 1.0.3884.0으로 업데이트 이후 ContactServiceModelPackage 오류 발생하는 문제
12549정성태3/4/20217485오류 유형: 700. VsixPublisher를 이용한 등록 시 다양한 오류 유형 해결책
12548정성태3/4/20218265개발 환경 구성: 546. github workflow/actions에서 nuget 패키지 등록하는 방법
12547정성태3/3/20218784오류 유형: 699. 비주얼 스튜디오 - The 'CascadePackage' package did not load correctly.
12546정성태3/3/20218406개발 환경 구성: 545. github workflow/actions에서 빌드시 snk 파일 다루는 방법 - Encrypted secrets
12545정성태3/2/202111127.NET Framework: 1026. 닷넷 5에 추가된 POH (Pinned Object Heap) [10]
12544정성태2/26/202111312.NET Framework: 1025. C# - Control의 Invalidate, Update, Refresh 차이점 [2]
12543정성태2/26/20219709VS.NET IDE: 158. C# - 디자인 타임(design-time)과 런타임(runtime)의 코드 실행 구분
12542정성태2/20/202112039개발 환경 구성: 544. github repo의 Release 활성화 및 Actions를 이용한 자동화 방법 [1]
12541정성태2/18/20219291개발 환경 구성: 543. 애저듣보잡 - Github Workflow/Actions 소개
12540정성태2/17/20219612.NET Framework: 1024. C# - Win32 API에 대한 P/Invoke를 대신하는 Microsoft.Windows.CsWin32 패키지
12539정성태2/16/20219489Windows: 189. WM_TIMER의 동작 방식 개요파일 다운로드1
12538정성태2/15/20219886.NET Framework: 1023. C# - GC 힙이 아닌 Native 힙에 인스턴스 생성 - 0SuperComicLib.LowLevel 라이브러리 소개 [2]
12537정성태2/11/202110875.NET Framework: 1022. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! - 두 번째 이야기 [2]
12536정성태2/9/20219913개발 환경 구성: 542. BDP(Bandwidth-delay product)와 TCP Receive Window
12535정성태2/9/20219037개발 환경 구성: 541. Wireshark로 확인하는 LSO(Large Send Offload), RSC(Receive Segment Coalescing) 옵션
12534정성태2/8/20219648개발 환경 구성: 540. Wireshark + C/C++로 확인하는 TCP 연결에서의 closesocket 동작 [1]파일 다운로드1
12533정성태2/8/20219293개발 환경 구성: 539. Wireshark + C/C++로 확인하는 TCP 연결에서의 shutdown 동작파일 다운로드1
12532정성태2/6/20219808개발 환경 구성: 538. Wireshark + C#으로 확인하는 ReceiveBufferSize(SO_RCVBUF), SendBufferSize(SO_SNDBUF) [3]
12531정성태2/5/20218786개발 환경 구성: 537. Wireshark + C#으로 확인하는 PSH flag와 Nagle 알고리듬파일 다운로드1
12530정성태2/4/202112930개발 환경 구성: 536. Wireshark + C#으로 확인하는 TCP 통신의 Receive Window
12529정성태2/4/202110051개발 환경 구성: 535. Wireshark + C#으로 확인하는 TCP 통신의 MIN RTO [1]
12528정성태2/1/20219434개발 환경 구성: 534. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 윈도우 환경
12527정성태2/1/20219665개발 환경 구성: 533. Wireshark + C#으로 확인하는 TCP 통신의 MSS(Maximum Segment Size) - 리눅스 환경파일 다운로드1
12526정성태2/1/20217519개발 환경 구성: 532. Azure Devops의 파이프라인 빌드 시 snk 파일 다루는 방법 - Secure file
... 31  32  33  34  35  36  37  38  39  40  41  42  [43]  44  45  ...