Microsoft MVP성태의 닷넷 이야기
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
(연관된 글이 2개 있습니다.)

연산자 재정의(operator overloading)와 메서드 재정의(method overriding)의 다른 점 - 가상 함수 호출 여부

영어의 override와 overload는 다른 의미이지만, 묘하게도 이것이 한글로 변환되었을 때 2가지 모두 '재정의'라고 번역되었는데요. 이 2가지 방식의 분명한 차이점이 하나 있다면 바로! 메서드 오버라이딩은 가상 함수 테이블(vtable: virtual function table)을 기반으로 동작한다는 점입니다.

예를 들어 다음의 코드는,

using System;

class Program
{
    static void Main(string[] args)
    {
        Program p1 = new Program();
        Program p2 = new Program();
        bool result1 = p1 == p2;
    }

    public static bool operator ==(Program objA, Program objB)
    {
        if (System.Object.ReferenceEquals(objA, objB))
        {
            return true;
        }

        if (((object)objA == null) || ((object)objB == null))
        {
            return false;
        }

        return objA.Equals(objB);
    }

    public static bool operator !=(Program objA, Program objB)
    {
        return !(objA == objB);
    }
}

'operator ==' 메서드를 재정의하고 있는데, == 메서드 내부에 정지점(BP: Breakpoint)를 걸고 F5 디버깅으로 실행해 보면 'bool result1 = p1 == p2;' 코드 실행 시 '==' 메서드 내부에 진입하는 것을 확인할 수 있습니다. (또는, 그냥 Console.WriteLine 코드를 넣어 실행 여부를 판단하면 되겠지요.)

하지만, Program 인스턴스가 아닌 object로 형변환해서 비교를 해보면 어떻게 될까요?

static void Main(string[] args)
{
    Program p1 = new Program();
    Program p2 = new Program();
    bool result1 = p1 == p2;

    object po1 = p1;
    object po2 = p2;
    bool result2 = po1 == po2;
}

두번째인 'po1 == po2' 비교 연산 수행 시에는 정지점이 걸리지 않게 됩니다. 왜냐하면, 재정의한 'operator ==' 연산자는 가상 함수 테이블을 이용한 구현이 아닌, 정적 함수 호출에 해당하므로 가상(virtual) 함수 호출이 발생하지 않기 때문입니다.




좀 더 깊게 들어가 볼까요? ^^

연산자를 사용하는 경우 C# 컴파일러는 재정의 유무에 따라 다른 IL 코드를 내놓습니다. 연산자가 재정의되지 않은 경우, 가령 System.Object는 'operator =='에 대한 정의를 갖고 있지 않습니다. 그럴 때 C# 컴파일러는 ceq라는 IL 코드를 사용해 비교 연산 작업을 수행하도록 합니다.

OpCodes.Ceq Field
; https://docs.microsoft.com/ko-kr/dotnet/api/system.reflection.emit.opcodes.ceq

하지만, '==' 연산자의 피연산자 타입이 'operator =='를 재정의하고 있다면 그 함수를 호출하는 코드를 IL로 출력해 줍니다. 실제로 이 글의 예제를 IL 코드로 번역해 보면 Program 타입과 System.Object 타입에 따른 '==' 연산자의 대응 방식을 확인할 수 있습니다.

.method private hidebysig static void Main(string[] args) cil managed
{
    .entrypoint
    .maxstack 2
    .locals init (
        [0] class Program program,
        [1] class Program program2,
        [2] bool flag,
        [3] object obj2,
        [4] object obj3,
        [5] bool flag2)
    L_0000: nop 
    L_0001: newobj instance void Program::.ctor()
    L_0006: stloc.0 
    L_0007: newobj instance void Program::.ctor()
    L_000c: stloc.1 
    L_000d: ldloc.0 
    L_000e: ldloc.1 
    L_000f: call bool Program::op_Equality(class Program, class Program) // 피연산자가 Program 타입인 경우
    L_0014: stloc.2 
    L_0015: ldloc.0 
    L_0016: stloc.3 
    L_0017: ldloc.1 
    L_0018: stloc.s obj3
    L_001a: ldloc.3 
    L_001b: ldloc.s obj3
    L_001d: ceq  // 피연산자가 System.Object인 경우
    L_001f: stloc.s flag2
    L_0021: ret 
}




따라서, 주의할 점을 하나 정리해 보면?

아래와 같이 상속 관계를 가진 클래스가 있는 경우, 반드시 본연의 타입 변수 상태에서 연산자 호출을 해야 부작용이 없습니다.

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 == pdp2; // Key, Key2 필드 2개 모두를 비교하기 때문에 false를 반환하지만!

        Program pp3 = pdp1;
        Program pp4 = pdp2;
        bool result4 = pp3 == 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);
    }
}

이 점에 대해 여러분들은 어떻게 생각하세요? 왠지, 연산자 재정의도 가상 함수 호출 기반으로 해야 하는 게 당연하지 않을까요?




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 7/10/2021]

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

비밀번호

댓글 작성자
 



2015-03-02 12시59분
[spowner] 불변성 개체 (예 string)는 연산자 재정의로 가독성 있는 코드가 가능할 것 입니다.
불변성 개체라 할지라도 object에 대해서 연산자 재정의를 허용한다면.. 글쎄요 매우 혼란스러울 것 같은데요. 그래서 연산자 재정의는 static (같은 타입끼리) 로 한정짓는 것 같습니다.
실제로 string을 object로 변환한 후 == 연산자로 비교하면 False가 반환됩니다.

string v1 = "value";
string v2 = "value";
v1 = v1 + v1; // 상수 문자열에 대한 같은 참조를 막기 위해
v2 = v2 + v2; // 상수 문자열에 대한 같은 참조를 막기 위해
Console.WriteLine(v1 == v2); // true
object ov1 = v1;
object ov2 = v2;
Console.WriteLine(ov1 == ov2); // false 이고 false어야 한다고 생각합니다.
[guest]
2015-03-02 01시03분
[spowner] 연산자 재정의는 불변성 개체일 때, 혹은 struct에서 연산자 비교가 직관적인 경우에만 분별하여 적용하고
연산자 재정의는 override 가 안되는게 맞다고 생각합니다.
[guest]
2015-03-03 12시06분
@spowner 그러게요. 그런 규칙을 적용하는 것이 맞을 것 같습니다. 이를 위한 정적 코드 분석이 있다면 좋겠군요. ^^
정성태

... 61  62  63  64  65  66  67  68  69  70  71  72  73  74  [75]  ...
NoWriterDateCnt.TitleFile(s)
12153정성태2/23/202024343.NET Framework: 898. Trampoline을 이용한 후킹의 한계파일 다운로드1
12152정성태2/23/202021372.NET Framework: 897. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 세 번째 이야기(Trampoline 후킹)파일 다운로드1
12151정성태2/22/202024021.NET Framework: 896. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 - 두 번째 이야기 (원본 함수 호출)파일 다운로드1
12150정성태2/21/202024097.NET Framework: 895. C# - Win32 API를 Trampoline 기법을 이용해 C# 메서드로 가로채는 방법 [1]파일 다운로드1
12149정성태2/20/202021005.NET Framework: 894. eBEST C# XingAPI 래퍼 - 연속 조회 처리 방법 [1]
12148정성태2/19/202025651디버깅 기술: 163. x64 환경에서 구현하는 다양한 Trampoline 기법 [1]
12147정성태2/19/202020978디버깅 기술: 162. x86/x64의 기계어 코드 최대 길이
12146정성태2/18/202022188.NET Framework: 893. eBEST C# XingAPI 래퍼 - 로그인 처리파일 다운로드1
12145정성태2/18/202023808.NET Framework: 892. eBEST C# XingAPI 래퍼 - Sqlite 지원 추가파일 다운로드1
12144정성태2/13/202024003.NET Framework: 891. 실행 시에 메서드 가로채기 - CLR Injection: Runtime Method Replacer 개선 - 두 번째 이야기파일 다운로드1
12143정성태2/13/202018411.NET Framework: 890. 상황별 GetFunctionPointer 반환값 정리 - x64파일 다운로드1
12142정성태2/12/202022317.NET Framework: 889. C# 코드로 접근하는 MethodDesc, MethodTable파일 다운로드1
12141정성태2/10/202021316.NET Framework: 888. C# - ASP.NET Core 웹 응용 프로그램의 출력 가로채기 [2]파일 다운로드1
12140정성태2/10/202022673.NET Framework: 887. C# - ASP.NET 웹 응용 프로그램의 출력 가로채기파일 다운로드1
12139정성태2/9/202022333.NET Framework: 886. C# - Console 응용 프로그램에서 UI 스레드 구현 방법
12138정성태2/9/202028575.NET Framework: 885. C# - 닷넷 응용 프로그램에서 SQLite 사용 [6]파일 다운로드1
12137정성태2/9/202020212오류 유형: 592. [AhnLab] 경고 - 디버거 실행을 탐지했습니다.
12136정성태2/6/202021870Windows: 168. Windows + S(또는 Q)로 뜨는 작업 표시줄의 검색 바가 동작하지 않는 경우
12135정성태2/6/202027662개발 환경 구성: 468. Nuget 패키지의 로컬 보관 폴더를 옮기는 방법 [2]
12134정성태2/5/202024932.NET Framework: 884. eBEST XingAPI의 C# 래퍼 버전 - XingAPINet Nuget 패키지 [5]파일 다운로드1
12133정성태2/5/202022695디버깅 기술: 161. Windbg 환경에서 확인해 본 .NET 메서드 JIT 컴파일 전과 후 - 두 번째 이야기
12132정성태1/28/202025723.NET Framework: 883. C#으로 구현하는 Win32 API 후킹(예: Sleep 호출 가로채기) [1]파일 다운로드1
12131정성태1/27/202024438개발 환경 구성: 467. LocaleEmulator를 이용해 유니코드를 지원하지 않는(한글이 깨지는) 프로그램을 실행하는 방법 [1]
12130정성태1/26/202022027VS.NET IDE: 142. Visual Studio에서 windbg의 "Open Executable..."처럼 EXE를 직접 열어 디버깅을 시작하는 방법
12129정성태1/26/202029016.NET Framework: 882. C# - 키움 Open API+ 사용 시 Registry 등록 없이 KHOpenAPI.ocx 사용하는 방법 [3]
12128정성태1/26/202023147오류 유형: 591. The code execution cannot proceed because mfc100.dll was not found. Reinstalling the program may fix this problem.
... 61  62  63  64  65  66  67  68  69  70  71  72  73  74  [75]  ...