Microsoft MVP성태의 닷넷 이야기
글쓴 사람
홈페이지
첨부 파일

C# - 값 형식의 readonly 인스턴스에 대한 메서드 호출 시 defensive copy 발생

readonly 예약어가 기본형 타입에 적용되었을 때에는 명확하게 읽기 전용이 됩니다. 그런데, 클래스나 구조체 타입의 인스턴스에 대해서는 다소 의미가 달라집니다.

예를 들어, 다음의 사용 예를 보겠습니다.

using System;

class Program
{
    readonly StructPerson sarah = new StructPerson() { Name = "Kerrigan", Age = 27 };
    readonly ClassPerson james = new ClassPerson() { Name = "Raynor", Age = 30 };

    static void Main(string[] args)
    {
        Program pg = new Program();
        pg.Test();
    }

    private void Test()
    {
        // sarah.Age = 32; // 컴파일 오류: CS1648 Members of readonly field 'Program.sarah' cannot be modified (except in a constructor or a variable initializer)
        james.Age = 32; // 참조 형식의 경우 readonly 인스턴스의 멤버는 대입 가능

        Console.WriteLine("sarah age: " + sarah.Age);
        Console.WriteLine("james age: " + james.Age); // 출력 결과: james age: 32
    }
}

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

class ClassPerson
{
    public int Age;
    public string Name;
}

보는 바와 같이, readonly는 값 형식에 대해서는 필드의 변경에 대해 컴파일 시 체크를 하지만 참조 형식의 경우에는 허용합니다. (참조 형식의 특성상 readonly에 대한 이러한 동작은 당연하다고도 할 수 있습니다.)

문제는 값 형식의 readonly 인스턴스입니다. 위의 경우 필드에 대해서는 컴파일러가 막을 수 있었지만 다음과 같은 메시지 호출에 대해서는 - 그리고 그 메서드의 내부에서 필드 값을 바꾸는 코드까지 막지는 않습니다.

private void Test()
{
    sarah.IncAge();
    james.IncAge();
    
    Console.WriteLine("sarah age: " + sarah.Age); // 출력 결과: sarah age: 27
    Console.WriteLine("james age: " + james.Age); // 출력 결과: james age: 31
}

struct StructPerson
{
    public int Age;
    public string Name;

    public void IncAge()
    {
        Age++;
    }
}

class ClassPerson
{
    public int Age;
    public string Name;

    public void IncAge()
    {
        Age++;
    }
}

즉, 필드를 변경할 수 없게 만들었던 것과는 달리 위의 소스 코드는 값 형식의 readonly 필드에 대해서도 IncAge 메서드 호출이 잘 됩니다. 그런데 출력 결과를 보면 재미있습니다. 위에서 보다시피 "sarah age: 27: 상태에서 IncAge 메서드를 호출했는데도 불구하고 여전히 27로 출력이 되고 있습니다. 어떻게 이럴 수 있는 걸까요?

그 이면에는 C# 컴파일러의 숨은 노력이 들어 있습니다. 실제로 C# 컴파일러는 readonly 인스턴스가 값 형식일 때 그것의 메서드나 공용 속성을 접근하는 코드에 대해 사전에 임시 변수를 만들어 대신 호출하도록 바꿉니다. 아래는 값 형식인 sarah와 참조 형식인 james의 IncAge 호출 코드를 IL 언어로 나타낸 것입니다.

IL_0001: ldarg.0      // this
IL_0002: ldfld        valuetype readonly_value_ref.StructPerson readonly_value_ref.Program::sarah
IL_0007: stloc.0      // V_0
IL_0008: ldloca.s     V_0
IL_000a: call         instance void readonly_value_ref.StructPerson::IncAge()
IL_000f: nop          

IL_0010: ldarg.0      // this
IL_0011: ldfld        class readonly_value_ref.ClassPerson readonly_value_ref.Program::james
IL_0016: callvirt     instance void readonly_value_ref.ClassPerson::IncAge()
IL_001b: nop          

이것을 평범한 C# 코드로 다시 나타내면 이렇습니다.

StructPerson temp = sarah;
temp.IncAge();

james.IncAge();

sarah가 값 형식의 인스턴스이기 때문에 temp에 대입하게 되면 전체 값 복사가 수행됩니다. 그리고 그렇게 복사된 인스턴스에 대해 IncAge를 호출하는 것이기 때문에 원래의 sarah 인스턴스는 상태가 바뀌지 않고 - 마치 readonly처럼 동작하는 결과를 낳습니다.

이렇게 상태 변경을 방지하기 위해 수행되는 복사를 일컬어 "defensive copy"라고 합니다.




개인적으로 defensive copy에 대해서는... 찬성/반대를 할 수가 없습니다. 값 형식의 readonly를 지킨다는 점에서 일관성을 지니고 있지만, 때로는 그것이 소스 코드에 나타나지 않고 컴파일러에 의해 숨겨진 유형으로 실행되기 때문에 버그가 발생할 여지가 있습니다. 일례로 다음의 글에 나온,

The 'in'-modifier and the readonly structs in C#
; https://blogs.msdn.microsoft.com/seteplia/2018/03/07/the-in-modifier-and-the-readonly-structs-in-c/

예제 코드를 보겠습니다.

internal class ReadOnlyEnumerator
{
    private readonly List<int>.Enumerator _enumerator;
 
    public ReadOnlyEnumerator(List<int> list)
    {
        _enumerator = list.GetEnumerator();
    }
 
    public void PrintTheFirstElement()
    {
        _enumerator.MoveNext();
        Console.WriteLine(_enumerator.Current); // 출력 결과: 0
    }
}

var roe = new ReadOnlyEnumerator(new List<int>{1,2});
roe.PrintTheFirstElement();

충분히 위와 같이 코드를 만들 수 있습니다. 그런데, 왜? 출력 결과로 0이 나오는지 한참을 고민하게 만들 수도 있습니다. 위의 경우 List<int>.Enumerator 타입이 struct입니다. 따라서 그것의 readonly 필드를 정의했기 때문에 PrintTheFirstElement 내의 코드는 MoveNext 메서드와 Current 공용 속성의 접근에 대해 개별적으로 모두 "defensive copy"가 발생합니다. 그래서 IL 코드로는 다음과 같은 코드로 변환되는 것입니다.

public void PrintTheFirstElement_Decompiled()
{
    // 첫 번째 Defensive copy 발생
    var localEnumerator = _enumerator;
    localEnumerator.MoveNext();
 
    // 두 번째 Defensive copy 발생
    localEnumerator = _enumerator;
    Console.WriteLine(localEnumerator.Current);
}

위와 같은 코드 사용을 방지하려면, 애당초 List<int>.Enumerator 타입이 struct라는 정보를 알고 있어야 합니다. 그것만 알았어도 굳이 readonly 필드로 변경할 필요가 없었을 것이고, 만약 readonly로 바꾸고 싶었다면 반드시 "defensive copy"에 대한 사전 정보를 알고 있어야만 저런 식으로 결과가 나왔을 때 문제의 원인을 파악할 수 있게 됩니다.

과연 어느 것이 옳은 것일까요? 일관성이 중요할까요? 일관성을 해치면서 동작하는 코드가 중요할까요? ^^

(첨부 파일은 이에 대한 예제 코드를 포함합니다.)




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

[연관 글]





[최초 등록일: ]
[최종 수정일: 5/15/2018 ]

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

비밀번호

댓글 쓴 사람
 



2018-05-23 12시59분
한글 도움말에 보면, "defensive copy"를 "방어 복사본"으로 번역했군요. ^^

값 형식과 참조 의미 체계
; https://docs.microsoft.com/ko-kr/dotnet/csharp/reference-semantics-with-value-types
정성태

... 16  17  18  19  20  21  22  23  24  [25]  26  27  28  29  30  ...
NoWriterDateCnt.TitleFile(s)
11562정성태6/26/20181913개발 환경 구성: 385. 레지스트리에 등록된 원격지 스크립트 COM 객체 실행 방법
11561정성태6/26/20183881.NET Framework: 777. UI 요소의 접근은 반드시 그 UI를 만든 스레드에서! [3]파일 다운로드1
11560정성태3/2/20191820.NET Framework: 776. C# 7.3 - 초기화 식에서 변수 사용 가능(expression variables in initializers)파일 다운로드1
11559정성태1/27/20203986개발 환경 구성: 384. 영문 설정의 Windows 10 명령행 창(cmd.exe)의 한글 지원 [3]
11558정성태6/25/20182292.NET Framework: 775. C# 7.3 - unmanaged(blittable) 제네릭 제약파일 다운로드1
11557정성태6/22/20182605.NET Framework: 774. C# - blittable 타입이란?파일 다운로드1
11556정성태6/25/20184741.NET Framework: 773. C# 7.3 - 구조체의 고정 크기를 갖는 fixed 배열 필드에 대한 직접 접근 가능 [1]파일 다운로드1
11555정성태6/25/20182192.NET Framework: 772. C# 7.3 - 사용자 정의 타입에 fixed 적용 가능(Custom fixed)파일 다운로드1
11554정성태6/25/20182325.NET Framework: 771. C# 7.3 - 자동 구현 속성에 특성 적용 가능(Attribute on backing field)
11553정성태6/25/20182579.NET Framework: 770. C# 7.3 - 개선된 메서드 선택 규칙 3가지(Improved overload candidates)파일 다운로드1
11552정성태6/25/20182513.NET Framework: 769. C# 7.3에서 개선된 문법 4개(Support == and != for tuples, Ref Reassignment, Constraints, Stackalloc initializers)파일 다운로드1
11551정성태6/14/20181702개발 환경 구성: 383. BenchmarkDotNet 사용 시 주의 사항
11550정성태6/13/20182101.NET Framework: 768. BenchmarkDotNet으로 Span<T> 성능 측정
11549정성태6/13/20181822개발 환경 구성: 382. BenchmarkDotNet에서 생성한 BuildPlots.R 파일을 실행하는 방법
11548정성태6/13/20182102오류 유형: 470. .NET Core + BenchmarkDotNet 실행 시 프레임워크를 찾지 못하는 문제
11547정성태6/13/20182350.NET Framework: 767. BenchmarkDotNet 라이브러리 소개파일 다운로드1
11546정성태6/14/20183160.NET Framework: 766. C# 7.2의 특징 - GC 및 메모리 복사 방지를 위한 struct 타입 개선 [4]파일 다운로드1
11545정성태6/11/20182650오류 유형: 469. .NET Core 프로젝트를 Visual Studio에서 실행 시 System.BadImageFormatException 발생하는 경우 [1]
11544정성태6/10/20182314.NET Framework: 765. C# 7.2 - 숫자 리터럴의 선행 밑줄과 뒤에 오지 않는 명명된 인수
11543정성태6/10/20182077.NET Framework: 764. C# 7.2 - private protected 접근자 추가파일 다운로드1
11542정성태6/9/20182571개발 환경 구성: 381. Azure Web App 확장 예제 - Remove Custom Headers
11541정성태9/14/20182182개발 환경 구성: 380. Azure Web App 확장 배포 방법 [1]
11540정성태6/9/20182386개발 환경 구성: 379. Azure Web App 확장 예제 제작 [2]
11539정성태6/8/20181997.NET Framework: 763. .NET Core 2.1 - Tiered Compilation 도입파일 다운로드1
11538정성태6/8/20181796.NET Framework: 762. .NET Core 2.1 - 확장 도구(Tools) 관리
11537정성태6/8/20183066.NET Framework: 761. C# - SmtpClient로 SMTP + SSL/TLS 서버를 이용하는 방법 [4]
... 16  17  18  19  20  21  22  23  24  [25]  26  27  28  29  30  ...