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

C# - 조건 연산자(?:)를 사용하는 경우 달라지는 메서드 선택 사례

이번 C# 9.0의 "target-typed conditional expression" 제안 문서를 보면,

Target-Typed Conditional Expression
; https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/proposals/csharp-9.0/target-typed-conditional-expression

재미있는 예제가 하나 나옵니다. 이것을 정리해 보면, 예를 들어 다음과 같이 호출하는 경우와,

using System;

class Program
{
    static void Main(string[] args)
    {
        M(1);
        M(2);
    }

    static void M(short n) { Console.WriteLine("Short"); }
    static void M(long n) { Console.WriteLine("Long"); }
}

/* 출력 결과
Short
Short
*/

3항 연산자로 다루는 경우가 다르다는 점입니다.

using System;

class Program
{
    static void Main(string[] args)
    {
        M((args.Length == 0) ? 1 : 2);
        M((args.Length == 1) ? 1 : 2);
    }

    static void M(short n) { Console.WriteLine("Short"); }
    static void M(long n) { Console.WriteLine("Long"); }
}

/* 출력 결과
Long
Long
*/




이에 대해 정확히 파악하려면, 언어 명세를 봐야 합니다. 실제로 아래의 문서를 보면,

Constant expressions
; https://learn.microsoft.com/en-us/dotnet/csharp/language-reference/language-specification/expressions#constant-expressions

명확하게 "Constant expressions"에 대해,

constant_expression
    : expression
    ;

숫자형의 범위에 따라 암시적인 형변환을 허용한다고 명시하고 있습니다.

An implicit constant expression conversion (Implicit constant expression conversions) permits a constant expression of type int to be converted to sbyte, byte, short, ushort, uint, or ulong, provided the value of the constant expression is within the range of the destination type.


즉, constant_expression인 경우 -128 ~ 127 범위의 숫자 리터럴이면 그 범위에 따라 short로 암시적 형변환을 허용하는 것입니다. 반면, 예제로 들었던 조건 연산자 식은 컴파일 타임에 식 자체가 constant_expression으로 표현되는 것은 아니므로 '범위에 따른 암시적 형변환'의 혜택을 받지 못합니다.

그런데, 재미있는 것은 "Constant expressions" 문서에 보면 다음의 대상이 constant_expression으로 허용된다고 하는데,

  • Literals (including the null literal).
  • References to const members of class and struct types.
  • References to members of enumeration types.
  • References to const parameters or local variables
  • Parenthesized sub-expressions, which are themselves constant expressions.
  • Cast expressions, provided the target type is one of the types listed above.
  • checked and unchecked expressions
  • Default value expressions
  • Nameof expressions
  • The predefined +, -, !, and ~ unary operators.
  • The predefined +, -, *, /, %, <<, >>, &, |, ^, &&, ||, ==, !=, <, >, <=, and >= binary operators, provided each operand is of a type listed above.
  • The ?: conditional operator.

마지막에 조건 연산자가 나옵니다. 따라서, 메서드를 다음과 같이 호출하면,

M((3 == 4) ? 1 : 2); // M(short)

컴파일 시점에 조건 연산자 식의 값이 결정되므로 constant_expression으로 평가받게 되고 결국 M(short) 버전의 메서드가 호출됩니다.

여기서 유의할 것은, 숫자 리터럴에 대한 constant_expression의 암시적 형변환이 대상 타입으로 int가 없을 때 발생하는 것이지, 그것 자체가 값의 범위에 따라 평가받는 것은 아니라는 점입니다.

즉, 원래 숫자 리터럴의 타입은 Int32(범위를 넘어서면 Int64)입니다.

Console.WriteLine("1 == " + 1.GetType().FullName); // System.Int32
Console.WriteLine("21474836473 == " + 21474836473.GetType().FullName); // System.Int64

var tenaryResult = (3 == 4) ? 1 : 2;
Console.WriteLine(tenaryResult.GetType().FullName); // System.Int32

그래서 만약 M(int)에 해당하는 메서드가 있었다면 M(1)로 호출해도 constant_expression의 암시적 형변환 단계를 거칠 필요 없이 M(int) 메서드가 선택이 됩니다.




그런데, 재미있는 경우가 하나 더 있습니다. C# 8.0에서 나온 새로운 switch expression은,

{
    bool result = args.Length == 1;
    M(result switch { true => 1, false => 2 }); // calls M(short)
}

코딩 결과로 보면 조건 연산자와 동일한 역할을 하지만 short 버전의 메서드가 선택된다는 것입니다. 이것 역시 언어 명세를 보면 이에 대한 설명이 나옵니다.

Switch Expression
; https://github.com/dotnet/csharplang/blob/a17f4c8ba82ed19fdad8b9f86ac151a443c89b08/proposals/csharp-8.0/patterns.md#switch-expression

The type of the switch_expression is the best common type of the expressions appearing to the right of the => tokens of the switch_expression_arms if such a type exists and the expression in every arm of the switch expression can be implicitly converted to that type.


즉, switch 식의 경우에는 모든 조건의 우측 operand를 기준으로 평가를 진행해 암시적 형변환 유무를 결정한다는 것입니다. 아마도 C# 언어 개발자들은 조건 연산자에 대해서도 2항과 3항 operand를 모두 평가해 암시적 형변환을 결정하는 것도 가능했을 것입니다. 하지만, 최초 C# 1.0 버전에서 그 작업을 진행하지 않았었고, 이후 버전 업이 되면서 그것을 switch 식처럼 모두 평가해 타입을 결정하는 것으로 변경했다면 하위 호환성이 깨지는 이유로 그대로 두었을 가능성이 큽니다. (어느 날 C# 9.0으로 빌드했는데 프로그램 동작이 바뀐다면 얼마나 황당하겠습니까? ^^;)




언어 스펙에 따른 원인을 밝혔으니, 마지막으로 IL 코드 상의 차이점을 파악해 볼까요? ^^ (사실 IL 코드까지 출력된 상황에서는 이미 언어 스펙 상의 타입 결정이 완료된 상태이므로 큰 의미는 없습니다.)

첫 번째의 경우처럼 1과 2를 직접 전달하거나,

/* 0x000002B6 17           */ IL_005A: ldc.i4.1
/* 0x000002B7 2802000006   */ IL_005B: call      void ConsoleApp2.Program::M(int16)
/* 0x000002BC 00           */ IL_0060: nop
/* 0x000002BD 18           */ IL_0061: ldc.i4.2
/* 0x000002BE 2802000006   */ IL_0062: call      void ConsoleApp2.Program::M(int16)

-128 ~ 127 사이의 숫자를 전달하는 경우는 M(int16) 메서드를 선택해 IL 코드를 산출해 내고 있는 반면,

M(49);

/* 0x000002C4 1F31         */ IL_0068: ldc.i4.s  49
/* 0x000002C6 2802000006   */ IL_006A: call      void Program::M(int16)

조건 연산자를 사용하면,

/* 0x000002C6 02           */ IL_006A: ldarg.0
/* 0x000002C7 8E           */ IL_006B: ldlen
/* 0x000002C8 2C03         */ IL_006C: brfalse.s IL_0071

/* 0x000002CA 18           */ IL_006E: ldc.i4.2
/* 0x000002CB 2B01         */ IL_006F: br.s      IL_0072

/* 0x000002CD 17           */ IL_0071: ldc.i4.1

/* 0x000002CE 6A           */ IL_0072: conv.i8
/* 0x000002CF 2803000006   */ IL_0073: call      void ConsoleApp2.Program::M(int64)

마찬가지로 (ldc.i4.1, ldc.i4.2) 상수 명령어가 오지만 마지막에 conv.i8을 이용해 M(int64)를 부르기 위한 변환을 합니다. 뭐 이 정도!

(첨부 파일은 이 글의 예제 코드를 포함합니다.)




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

[연관 글]






[최초 등록일: ]
[최종 수정일: 3/9/2024]

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

비밀번호

댓글 작성자
 




... 61  [62]  63  64  65  66  67  68  69  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
12097정성태1/2/20209822디버깅 기술: 150. windbg - Wow64, x86, x64에서의 커널 구조체(예: TEB) 구조체 확인
12096정성태12/30/201911778디버깅 기술: 149. C# - DbgEng.dll을 이용한 간단한 디버거 제작 [1]
12095정성태12/27/201913244VC++: 135. C++ - string_view의 동작 방식
12094정성태12/26/201911404.NET Framework: 873. C# - 코드를 통해 PDB 심벌 파일 다운로드 방법
12093정성태12/26/201911467.NET Framework: 872. C# - 로딩된 Native DLL의 export 함수 목록 출력파일 다운로드1
12092정성태12/25/201910918디버깅 기술: 148. cdb.exe를 이용해 (ntdll.dll 등에 정의된) 커널 구조체 출력하는 방법
12091정성태12/25/201912413디버깅 기술: 147. pdb 파일을 다운로드하기 위한 symchk.exe 실행에 필요한 최소 파일 [1]
12090정성태12/24/201911125.NET Framework: 871. .NET AnyCPU로 빌드된 PE 헤더의 로딩 전/후 차이점 [1]파일 다운로드1
12089정성태12/23/201911708디버깅 기술: 146. gflags와 _CrtIsMemoryBlock을 이용한 Heap 메모리 손상 여부 체크
12088정성태12/23/201910658Linux: 28. Linux - 윈도우의 "Run as different user" 기능을 shell에서 실행하는 방법
12087정성태12/21/201911131디버깅 기술: 145. windbg/sos - Dictionary의 entries 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12086정성태12/20/201913158디버깅 기술: 144. windbg - Marshal.FreeHGlobal에서 발생한 덤프 분석 사례
12085정성태12/20/201910917오류 유형: 586. iisreset - The data is invalid. (2147942413, 8007000d) 오류 발생 - 두 번째 이야기 [1]
12084정성태12/19/201911521디버깅 기술: 143. windbg/sos - Hashtable의 buckets 배열 내용을 모두 덤프하는 방법 (do_hashtable.py) [1]
12083정성태12/17/201912782Linux: 27. linux - lldb를 이용한 .NET Core 응용 프로그램의 메모리 덤프 분석 방법 [2]
12082정성태12/17/201912615오류 유형: 585. lsof: WARNING: can't stat() fuse.gvfsd-fuse file system
12081정성태12/16/201914395개발 환경 구성: 465. 로컬 PC에서 개발 중인 ASP.NET Core 웹 응용 프로그램을 다른 PC에서도 접근하는 방법 [5]
12080정성태12/16/201912266.NET Framework: 870. C# - 프로세스의 모든 핸들을 열람
12079정성태12/13/201913570오류 유형: 584. 원격 데스크톱(rdp) 환경에서 다중 또는 고용량 파일 복사 시 "Unspecified error" 오류 발생
12078정성태12/13/201913460Linux: 26. .NET Core 응용 프로그램을 위한 메모리 덤프 방법 [3]
12077정성태12/13/201913055Linux: 25. 자주 실행할 명령어 또는 초기 환경을 "~/.bashrc" 파일에 등록
12076정성태12/12/201911227디버깅 기술: 142. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅 - 배포 방법에 따른 차이
12075정성태12/11/201912071디버깅 기술: 141. Linux - lldb 환경에서 sos 확장 명령어를 이용한 닷넷 프로세스 디버깅
12074정성태12/10/201911684디버깅 기술: 140. windbg/Visual Studio - 값이 변경된 경우를 위한 정지점(BP) 설정(Data Breakpoint)
12073정성태12/10/201913493Linux: 24. Linux/C# - 실행 파일이 아닌 스크립트 형식의 명령어를 Process.Start로 실행하는 방법
12072정성태12/9/201910926오류 유형: 583. iisreset 수행 시 "No such interface supported" 오류
... 61  [62]  63  64  65  66  67  68  69  70  71  72  73  74  75  ...