== 연산자보다는 Equals 메서드의 호출이 더 권장됩니다.
'== 연산자'와 Equals 메서드에 대한 상세 내용은 다음의 문서에 잘 정리되어 있습니다.
Guidelines for Overriding Equals() and Operator == (C# Programming Guide)
; https://learn.microsoft.com/en-us/previous-versions/ms173147(v=vs.90)
다시 위의 글을 한번 정리해 보면, '같다'는 연산 의미는 크게 다음의 2가지 범주로 나눌 수 있고,
- 참조 주소 값 같음. - reference equality (also known as identity)
- 값이 같음. - value equality
관련해서 우리가 '같음'을 판단하는 데 사용하는 코드는 이렇게 나뉩니다.
- == 연산자
- object.Equals 메서드
자, 그럼 '== 연산자'와 'object.Equals' 메서드가 어떻게 다른지 한번 파고들어가 볼까요? ^^
'== 연산자(
ceq)'는 참조형 변수의 주소값을 비교하는 object.ReferenceEquals 메서드에도 내부적으로 사용됩니다.
// Generated by .NET Reflector from C:\Windows\Microsoft.Net\assembly\GAC_64\mscorlib\v4.0_4.0.0.0__b77a5c561934e089\mscorlib.dll
namespace System
{
// ...[생략]...
[Serializable, ComVisible(true), ClassInterface(ClassInterfaceType.AutoDual), __DynamicallyInvokable]
public class Object
{
// ...[생략]...
public static bool ReferenceEquals(object objA, object objB)
{
return (objA == objB);
}
}
}
하지만 지난번 글에서 이야기한대로,
연산자 재정의(operator overloading)와 메서드 재정의(method overriding)의 다른 점 - 가상 함수 호출 여부
; https://www.sysnet.pe.kr/2/0/2877
"(objA == objB)" 비교 코드는 object 타입이므로 개발자가 별도로 정의한 '[Type].operator ==' 메서드가 호출되지 않고 ceq 연산자 본연의 비교 연산이 수행됩니다. 이를 반영해서 '== 연산'을 정의하면 다음과 같이 정리됩니다.
- object.ReferenceEquals 메서드, ceq(기본 == 연산자): reference equality에 해당
- 사용자 정의 '== 연산자': equality 기준을 개발자가 정의
object.ReferenceEquals 메서드와 ceq(기본 == 연산자)의 기본 동작은 "참조 주소 값 같음. - reference equality (also known as identity)"에 해당합니다. 즉, 관리 힙에 할당된 객체의 참조 주소 값을 비교해 '같음 여부'를 판단하는 것입니다. 이 때문에, object.ReferenceEquals 메서드와 ceq(기본 == 연산자)는 '값 형식'의 인스턴스에 사용해서는 안됩니다.
실제로 '== 연산자'를 값 형식의 변수에 적용하려고 하면 C# 컴파일러는 CS0019 컴파일 오류를 발생시킵니다.
using System;
public struct StructTest
{
int key;
public int Key { get { return key; } set { key = value; } }
}
class Program
{
static void Main(string[] args)
{
StructTest t1 = new StructTest { Key = 5 };
StructTest t2 = new StructTest { Key = 5 };
// CS0019: Operator '==' cannot be applied to operands of type 'StructTest' and 'StructTest'
//Console.WriteLine(t1 == t2);
// ceq IL 코드는 값 형식에 적용해서는 안됨!
}
}
왜냐하면, 값 형식은 스택에 값이 할당되기 때문에 관리 힙에 대한 참조 형 주소가 없기 때문입니다. 이렇게 ceq IL 코드로 처리되는 '== 연산자'와는 달리 object.ReferenceEquals는 메서드 호출이기 때문에 컴파일 오류까지 발생하지는 않습니다.
using System;
public struct StructTest
{
int key;
public int Key { get { return key; } set { key = value; } }
}
class Program
{
static void Main(string[] args)
{
StructTest t1 = new StructTest { Key = 5 };
StructTest t2 = new StructTest { Key = 5 };
StructTest t3 = t1;
Console.WriteLine("object.ReferenceEquals(t1, t2): " + object.ReferenceEquals(t1, t2)); // 출력 결과: False
Console.WriteLine("object.ReferenceEquals(t1, t3): " + object.ReferenceEquals(t1, t3)); // 출력 결과: False
}
}
하지만, 값 형식에 대해서는 언제나 false를 반환합니다. 왜냐하면, object.ReferenceEquals 메서드는 인자를 모두 object 타입으로 받기 때문에 값 형식의 인스턴스를 전달해도 boxing이 발생해서 관리 힙에 별도의 영역을 차지하는 결과를 낳습니다. 따라서 참조 주소 값이 틀려지기 때문에 언제나 false를 반환합니다. 이 때문에 == 연산자 대신 특별한 이유없이 object.ReferenceEquals 메서드를 직접 호출하는 것은 그다지 바람직한 코딩 습관이 아닙니다. (object.ReferenceEquals를 값 형식에 사용하는 경우 개발자는 컴파일 오류가 없기 때문에 이를 알 수 없습니다.)
그런데 object.ReferenceEquals와 '== 연산자'의 다른 점도 있습니다. object.ReferenceEquals 메서드는 재정의(override)가 불가능한 반면, '== 연산자'는 재정의가 가능하다는 것입니다. 여기서도 다시 한번 알 수 있지만, "명시적인 참조 주소값의 비교가 아니라면 object.ReferenceEquals 메서드를 호출하기 보다 '== 연산자'를 사용하는 것"이 더 권장됩니다.
마지막으로, '== 연산자'의 호출은 지난번 글에도 알아봤지만,
연산자 재정의(operator overloading)와 메서드 재정의(method overriding)의 다른 점 - 가상 함수 호출 여부
; https://www.sysnet.pe.kr/2/0/2877
object.Equals 메서드와는 아무런 관련없는 IL 코드를 추가합니다. 즉, object.Equals 메서드와 == 연산자는 (인간 입장에서) 의미는 같으면서도 전혀 별개로 동작합니다.
그럼, 이제 object.Equals 메서드로 넘어가 볼까요? object.Equals 메서드의 내부를 보면, RuntimeHelpers.Equals 메서드로 연결됩니다.
namespace System
{
// ...[생략]...
public class Object
{
// ...[생략]...
public virtual bool Equals(object obj)
{
return RuntimeHelpers.Equals(this, obj);
}
}
}
그리고 RuntimeHelpers.Equals의 구현은 CLR 내부에 구현되어 있어 더 이상 추적이 되지 않습니다.
RuntimeHelpers.Equals Method (Object, Object)
; https://learn.microsoft.com/en-us/dotnet/api/system.runtime.compilerservices.runtimehelpers.equals
namespace System.Runtime.CompilerServices
{
// ...[생략]...
[__DynamicallyInvokable]
public static class RuntimeHelpers
{
// ...[생략]...
[MethodImpl(MethodImplOptions.InternalCall), SecuritySafeCritical]
public static extern bool Equals(object o1, object o2);
// ...[생략]...
}
}
기본 구현된 Equals 메서드(달리 말하면, RuntimeHelpers.Equals 메서드)는 'reference equality'를 기준으로 삼기 때문에 object.ReferenceEquals와 유사한 결과를 냅니다.
// 참조형에 대한 RuntimeHelpers.Equals 호출 테스트
// == object.Equals
// == object.ReferenceEquals
using System;
using System.Runtime.CompilerServices;
class Program
{
int key;
public int Key { get { return key; } set { key = value; } }
static void Main(string[] args)
{
Program p1 = new Program { Key = 5 };
Program p2 = new Program { Key = 5 };
Console.WriteLine("p1.Equals(p2): " + p1.Equals(p2)); // False
Console.WriteLine("object.ReferenceEquals(p1, p2): " + object.ReferenceEquals(p1, p2)); // False
Console.WriteLine("RuntimeHelpers.Equals(p1, p2): " + RuntimeHelpers.Equals(p1, p2)); // False
Console.WriteLine();
Program p3 = p1;
Console.WriteLine("p1.Equals(p3): " + p1.Equals(p3)); // True
Console.WriteLine("object.ReferenceEquals(p1, p3): " + object.ReferenceEquals(p1, p3)); // True
Console.WriteLine("RuntimeHelpers.Equals(p1, p3): " + RuntimeHelpers.Equals(p1, p3)); // True
}
}
값 형식에 대해서도 (object.ReferenceEquals 메서드 호출때와 유사하게) RuntimeHelpers.Equals 메서드의 인자로 object가 지정되어 있기 때문에 박싱이 발생해 참조 비교가 발생합니다.
// 값형식에 대한 RuntimeHelpers.Equals 호출 테스트
// != (object.Equals == object.ReferenceEquals)
int p1 = 5;
int p2 = 5;
Console.WriteLine("p1.Equals(p2): " + p1.Equals(p2)); // True
Console.WriteLine("object.ReferenceEquals(p1, p2): " + object.ReferenceEquals(p1, p2)); // False
Console.WriteLine("RuntimeHelpers.Equals(p1, p2): " + RuntimeHelpers.Equals(p1, p2)); // False
Console.WriteLine();
int p3 = p1;
Console.WriteLine("p1.Equals(p3): " + p1.Equals(p3)); // True
Console.WriteLine("object.ReferenceEquals(p1, p3): " + object.ReferenceEquals(p1, p3)); // False
Console.WriteLine("RuntimeHelpers.Equals(p1, p3): " + RuntimeHelpers.Equals(p1, p3)); // False
그런데, 참조 형식의 비교 때와 달리 값 형식에 대해서는 RuntimeHelpers.Equals와 object.Equals의 결과값이 다르게 나옵니다. 왜냐하면, object.Equals는 RuntimeHelpers.Equals와는 달리 System.Object 타입에 가상 함수(virtual function)로 제공되고 있기 때문에 하위 클래스에서 재정의하면 객체 지향의 다형성 혜택을 받게 됩니다. int 타입의 부모는 ValueType이고, ValueType은 Equals 메서드를 값 형식에 정의된 모든 필드를 일일이 비교하는 방식으로 재정의하고 있기 때문에 이런 동작을 보이는 것입니다.
정리하면, System.Object 클래스에 정의된 object.Equals 메서드가 내부적으로 RuntimeHelpers.Equals를 부르지만 가상 함수의 기능을 고려했을 때 RuntimeHelpers.Equals가 비록 public으로 공개된 메서드일지라도 가능한 object.Equals를 호출하는 것이 더 좋은 코딩 습관입니다.
이제 본론으로 들어가 보겠습니다. 이 글의 제목에서처럼, 제 개인적으로는 가능한 "Equals" 메서드의 호출을 권장합니다. 그 이유를 말하자면 우선 지난 글에 쓴 것처럼,
struct로 정의한 값 형식(Value Type)의 경우 Equals 재정의를 권장합니다.
; https://www.sysnet.pe.kr/2/0/2869
struct 타입에서도 Equals 재정의가 권장되기 때문입니다. 그리고 두 번째 이유는, '== 연산자'는 가상 함수 방식이 아니지만 'Equals'는 가상 함수 방식이기 때문입니다. 이에 대해서도 전에 이야기했었지요.
연산자 재정의(operator overloading)와 메서드 재정의(method overriding)의 다른 점 - 가상 함수 호출 여부
; https://www.sysnet.pe.kr/2/0/2877
위의 글 마지막에서 "연산자 재정의도 가상 함수 호출 기반으로 해야 하는 게 당연하지 않을까요?"라는 질문을 했는데요. 적어도 '비교' 구문에서만큼은 이것이 Equals 메서드의 사용으로 해결됩니다. "
연산자 재정의(operator overloading)와 메서드 재정의(method overriding)의 다른 점 - 가상 함수 호출 여부" 글에서 문제가 되었던 마지막 예제를,
using System;
class Program
{
public int Key;
static void Main(string[] args)
{
DerivedProgram pdp1 = new DerivedProgram { Key = 5, Key2 = 6 };
DerivedProgram pdp2 = new DerivedProgram { Key = 5, Key2 = 7 };
bool result3 = pdp1.Equals(pdp2); // Key, Key2 필드 2개 모두를 비교하기 때문에 false를 반환하지만!
Program pp3 = pdp1;
Program pp4 = pdp2;
bool result4 = pp3.Equals(pp4); // Key 필드 하나만 비교하므로 true를 반환
}
public static bool operator ==(Program objA, Program objB)
{
return objA.Key == objB.Key; // Key 필드 하나만 비교
}
public static bool operator !=(Program objA, Program objB)
{
return !(objA == objB);
}
}
class DerivedProgram : Program
{
public static bool operator ==(DerivedProgram objA, DerivedProgram objB)
{
return (objA.Key == objB.Key) && (objA.Key2 == objB.Key2); // Key, Key2 필드 2개 모두를 비교
}
public static bool operator !=(DerivedProgram objA, DerivedProgram objB)
{
return !(objA == objB);
}
}
Equals로 정리하면 말끔하게 해결됩니다.
using System;
class Program
{
public int Key;
static void Main(string[] args)
{
DerivedProgram pdp1 = new DerivedProgram { Key = 5, Key2 = 6 };
DerivedProgram pdp2 = new DerivedProgram { Key = 5, Key2 = 7 };
bool result3 = pdp1.Equals(pdp2);
Console.WriteLine(result3); // False
Program pp3 = pdp1;
Program pp4 = pdp2;
bool result4 = pp3.Equals(pp4);
Console.WriteLine(result4); // 형변환 했어도, 가상 함수이므로 False 반환
}
public override bool Equals(object obj)
{
if (obj == null)
{
return false;
}
Program target = obj as Program;
if (target == null)
{
return false;
}
return this.Key == target.Key;
}
}
class DerivedProgram : Program
{
public int Key2;
public override bool Equals(object obj)
{
if (obj == null)
{
return false;
}
DerivedProgram target = obj as DerivedProgram;
if (target == null)
{
return false;
}
return (this.Key == target.Key) && (this.Key2 == target.Key2);
}
}
물론, 모든 경우에 대해 Equals 메서드 호출을 강제하는 것은 코드 가독성 측면에서 그리 좋지 않을 수도 있습니다. 따라서 다음의 예외 정도는 두어도 좋을 듯 합니다. ^^
- null 비교하는 구문: 예를 들어 if (testobj == null)
- 기본 형식(primitive type)을 비교하는 구문: 예를 들어 int a = 100; if (a == 20)
(예외가 좋을 구문이 또 있을까요?) 개인적으로, 그 외에는 가능한 신경써서 Equals로 처리하는 것을 권장합니다.
참고로, 제가 한 가지 풀리지 않는 수수께끼가 하나 있습니다. 테스트 하다가 발견한 것인데, RuntimeHelpers.Equals와 object.ReferenceEquals의 차이점이 상수 값 호출에 대해 발생한다는 점입니다.
Console.WriteLine("5.Equals(5): " + 5.Equals(5)); // True
Console.WriteLine("object.ReferenceEquals(5, 5): " + object.ReferenceEquals(5, 5)); // False
Console.WriteLine("RuntimeHelpers.Equals(5, 5): " + RuntimeHelpers.Equals(5, 5)); // True
IL 코드를 보면, object.ReferenceEquals, RuntimeHelpers.Equals 메서드 호출 모두 그 전에 전달하는 인자를 boxing 처리하는데,
L_004e: ldc.i4.5
L_004f: box int32
L_0054: ldc.i4.5
L_0055: box int32
L_005a: call bool [mscorlib]System.Object::ReferenceEquals(object, object)
L_0074: ldc.i4.5
L_0075: box int32
L_007a: ldc.i4.5
L_007b: box int32
L_0080: call bool [mscorlib]System.Runtime.CompilerServices.RuntimeHelpers::Equals(object, object)
희한하게도, RuntimeHelpers.Equals 메서드는 그 결과로 값 비교에 준하는 결과를 내놓고 있습니다. (물론, 내부적으로 어떤 처리가 있긴 하겠지만! ^^;)
[이 글에 대해서 여러분들과 의견을 공유하고 싶습니다. 틀리거나 미흡한 부분 또는 의문 사항이 있으시면 언제든 댓글 남겨주십시오.]