Microsoft MVP성태의 닷넷 이야기
.NET Framework: 751. C# 7.2 - 메서드의 매개 변수에 in 변경자 추가 [링크 복사], [링크+제목 복사],
조회: 24614
글쓴 사람
정성태 (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]

... 136  [137]  138  139  140  141  142  143  144  145  146  147  148  149  150  ...
NoWriterDateCnt.TitleFile(s)
1629정성태2/5/201432552개발 환경 구성: 215. DOS batch - 하나의 .bat 파일에서 다중 .bat 파일을 (비동기로) 실행하는 방법 [1]
1628정성태2/4/201433905Windows: 87. 윈도우 8.1에서 .NET 3.5 설치가 안된다면? [2]
1627정성태2/4/201428982개발 환경 구성: 214. SQL Server Reporting Services를 이용해 간단한 리포트 제작하는 방법
1626정성태2/4/201420983Windows: 86. 윈도우 8.1의 Skydrive 내용이 동기화가 안된다면?
1625정성태2/2/201428185.NET Framework: 422. C++과 C#의 Event 공유파일 다운로드1
1624정성태2/2/201423787.NET Framework: 421. ASP.NET에서 Server.CreateObject와 COM Interop 클래스 생성의 차이점
1623정성태2/1/201428495개발 환경 구성: 213. x86/x64별로 나뉘어진 어셈블리를 한 프로젝트에서 참조하는 방법 [1]파일 다운로드1
1622정성태1/31/201428947VC++: 74. 어떤 것을 쓰면 좋을까요? wvnsprintf, _vsnwprintf_s, StringCbVPrintfW [4]
1621정성태1/31/201420774.NET Framework: 420. 베트남의 11학년(한국의 고2)이 45분만에 푼다는 알고리즘 문제파일 다운로드1
1620정성태1/30/201430587.NET Framework: 419. C# - BigDecimal파일 다운로드1
1619정성태1/30/201427324VS.NET IDE: 85. T4를 이용한 INotifyPropertyChanged 코드 자동 생성파일 다운로드1
1618정성태1/29/201443057Linux: 2. 우분투에서 Active Directory 계정을 이용한 파일 공유
1617정성태1/29/201424174.NET Framework: 418. Thread.Abort 호출의 hang 현상 [1]
1616정성태1/29/201424835디버깅 기술: 63. windbg 디버깅 사례: AppDomain 간의 static 변수 사용으로 인한 crash
1615정성태1/29/201426815.NET Framework: 417. WPF WebBrowser 컨트롤에서 SHDocVw.IWebBrowser2 인터페이스를 구하는 방법 및 순수 WPF 웹 브라우저 컨트롤 소개
1614정성태1/29/201423778.NET Framework: 416. System.Net.Sockets.NetworkStream이 Thread-safe할까?파일 다운로드1
1613정성태1/29/201425762.NET Framework: 415. IIS 작업자 프로세스 재생(recycle)하는 방법 [1]
1612정성태1/29/201422555오류 유형: 219. IIS 500 Internal Server Error - Skydrive에 공유된 경우
1611정성태1/27/201453947.NET Framework: 414. C# - 컴퓨터에서 알아낼 수 있는 고윳값 정리 [3]파일 다운로드1
1610정성태1/26/201437886.NET Framework: 413. C# - chromiumembedded 사용 [11]파일 다운로드1
1609정성태1/26/201420917오류 유형: 218. wsDualHttpBinding + Windows Server 2003인 경우 발생하는 오류
1608정성태1/26/201426191.NET Framework: 412. HttpContext.Current를 통해 이해하는 CallContext와 ExecutionContext [4]
1607정성태1/26/201426122.NET Framework: 411. 유니코드의 "compatibility character"가 뭘까요? [4]파일 다운로드1
1606정성태1/25/201424236오류 유형: 217. 델 베뉴 스타일러스 관련 업데이트 오류 - 5830_Firmware_X267N_WN_1.0.4.1_A01.EXE
1605정성태1/23/201421097개발 환경 구성: 212. Visual Studio Online과 "Monaco" 서비스 연동
1604정성태1/23/201421433오류 유형: 216. 윈도우 서버 백업 - Hyper-V 가상 머신이 백업되지 않는 경우 (2)
... 136  [137]  138  139  140  141  142  143  144  145  146  147  148  149  150  ...