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"에 대한 사전 정보를 알고 있어야만 저런 식으로 결과가 나왔을 때 문제의 원인을 파악할 수 있게 됩니다.
과연 어느 것이 옳은 것일까요? 일관성이 중요할까요? 일관성을 해치면서 동작하는 코드가 중요할까요? ^^
(
첨부 파일은 이에 대한 예제 코드를 포함합니다.)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]