Microsoft MVP성태의 닷넷 이야기
.NET Framework: 744. C# 6 - Expression bodied function [링크 복사], [링크+제목 복사],
조회: 21201
글쓴 사람
정성태 (techsharer at outlook.com)
홈페이지
첨부 파일
 
(연관된 글이 1개 있습니다.)

C# 6 - Expression bodied function

아래와 같은 글이 있군요. ^^

식 본문 함수의 최적화
왜 우리는 람다를 더 써야 하는가
; https://phillyai.github.io/2018-05-08-Expression-Bodied-Function/

위의 글에서는 다음의 2가지 메서드를,

int Add(int a, int b) { return a + b; }
int AddLambda(int a, int b) => a + b;

빌드했을 때, 람다 형식으로 작성한 경우 컴파일러가 더 최적화를 잘 해주기 때문이라고 합니다. 실제로 IL 코드로 보면 다음과 같이 차이가 납니다.

.method private hidebysig instance int32 Add(int32 a, int32 b) cil managed
{
    .maxstack 2
    .locals init (
        [0] int32 num)
    L_0000: nop 
    L_0001: ldarg.1 
    L_0002: ldarg.2 
    L_0003: add 
    L_0004: stloc.0 
    L_0005: br.s L_0007
    L_0007: ldloc.0 
    L_0008: ret 
}

.method private hidebysig instance int32 AddLambda(int32 a, int32 b) cil managed
{
    .maxstack 8
    L_0000: ldarg.1 
    L_0001: ldarg.2 
    L_0002: add 
    L_0003: ret 
}

보다시피 람다로 했을 때 코드가 더 간결합니다. 좀 더 기술적인 용어로 첫 번째 Add 메서드는 Fat method 형식이고, 두 번째 Lambda 메서드는 Thin method 형식입니다. 그런데, 사실 이건 Debug 모드로 빌드했기 때문에 나온 결과일 뿐입니다. Release 모드로 빌드하면 다음과 같이 2개 모두 동일한 IL 코드를 볼 수 있습니다.

.method private hidebysig instance int32 Add(int32 a, int32 b) cil managed
{
    .maxstack 8
    L_0000: ldarg.1 
    L_0001: ldarg.2 
    L_0002: add 
    L_0003: ret 
}

.method private hidebysig instance int32 AddLambda(int32 a, int32 b) cil managed
{
    .maxstack 8
    L_0000: ldarg.1 
    L_0001: ldarg.2 
    L_0002: add 
    L_0003: ret 
}

그러니까... 저런 이유로 굳이 람다를 더 쓸 필요는 없습니다.

참고로, 디버그 모드에서 람다 메서드가 더 최적화가 잘 되는 것은, 람다 메서드의 경우 tiny header를 가질 수 있는 요건을 쉽게 충족하기 때문입니다.




"왜 우리는 람다를 더 써야 하는가" 글에서 한 가지 더 이상한 점이 있는데요. 해당 최적화가 Expression에서만 적용되고 Statement에 대해 적용되지 않는다면서 쓴 코드가 바람직하지 않습니다.

void DoLambda() => Do();

위에서 DoLambda의 body 역시 (Statement가 아닌) Expression으로 작성된 것입니다. 저 구문의 영문 이름이 "Expression bodied function"인데요, 즉 저 구문에서는 반드시 Expression만 허용됩니다. 만약 저 코드를 Statement로 만들려면 다음과 같이 코딩해야 하는데,

void DoLambda() => { Do(); } // 컴파일 오류 - Error CS1525 Invalid expression term '{'

그럼 CS1525 컴파일 오류가 발생합니다. 왜냐하면 Expression에서는 블록이 허용되지 않기 때문입니다. (블록은 Statement에만 허용됩니다.)

사실 정확히 말하면 아래의 코드는,

int AddLambda(int a, int b) => a + b;

말 그대로 "Expression bodied function"입니다. 비록 C#의 람다 표현으로 작성하긴 했지만 expression만 허용됩니다. 반면, 람다 식이 아닌 람다 문을 활용하면 다음과 같이 쓸 수 있습니다.

static void Main(string[] args)
{
    Action action = () => // Statement를 가진 람다 메서드
    {
        Console.WriteLine();
    };
}

그러니까, "왜 우리는 람다를 더 써야 하는가" 글의 제목도 좀 맞지 않습니다. 실제로 저 글의 내용이 맞다고 가정했을 때 좀 더 정확히는 "왜 우리는 Expression bodied function을 사용해야 하는가"라고 해야 합니다.




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

[연관 글]






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

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

비밀번호

댓글 작성자
 



2021-07-24 10시34분
C#을 다루는 기술
; http://www.yes24.com/Product/Goods/101511486

위의 서적에 보면, 저자인 John Skeet이 "Expression bodied function"의 문법에서 사용한 "=>"는 람다 표현식이 아니다, 라고 합니다. 해당 기호에 따른 이후의 코드는 델리게이트나 표현식 트리와 무관하다는 것을 이유로 들고 있으며 단지 읽기 전용의 속성을 생성하라는 문법을 "=>"로 지시하는 역할만 한다고 합니다. 에고... 그동안 해당 구문을 람다 식이라고 제 책에서 써 왔는데, 고쳐야겠습니다. ^^;
정성태

1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...
NoWriterDateCnt.TitleFile(s)
13743정성태9/26/20246444닷넷: 2298. C# - Console 프로젝트에서의 await 대상으로 Main 스레드 활용하는 방법 [1]
13742정성태9/26/20246734닷넷: 2297. C# - ssh-keygen으로 생성한 ecdsa 유형의 Public Key 파일 해석 [1]파일 다운로드1
13741정성태9/25/20245922디버깅 기술: 202. windbg - ASP.NET MVC Web Application (.NET Framework) 응용 프로그램의 덤프 분석 시 요령
13740정성태9/24/20245771기타: 86. RSA 공개키 등의 modulus 값에 0x00 선행 바이트가 있는 이유(ASN.1 인코딩)
13739정성태9/24/20245921닷넷: 2297. C# - ssh-keygen으로 생성한 Public Key 파일 해석과 fingerprint 값(md5, sha256) 생성 [1]파일 다운로드1
13738정성태9/22/20245639C/C++: 174. C/C++ - 윈도우 운영체제에서의 file descriptor, FILE*파일 다운로드1
13737정성태9/21/20246001개발 환경 구성: 727. Visual C++ - 리눅스 프로젝트를 위한 빌드 서버의 msbuild 구성
13736정성태9/20/20246010오류 유형: 923. Visual Studio Code - Could not establish connection to "...": Port forwarding is disabled.
13735정성태9/20/20246079개발 환경 구성: 726. ARM 플랫폼용 Visual C++ 리눅스 프로젝트 빌드
13734정성태9/19/20245789개발 환경 구성: 725. ssh를 이용한 원격 docker 서비스 사용
13733정성태9/19/20246117VS.NET IDE: 194. Visual Studio - Cross Platform / "Authentication Type: Private Key"로 접속하는 방법
13732정성태9/17/20246170개발 환경 구성: 724. ARM + docker 환경에서 .NET 8 설치
13731정성태9/15/20246760개발 환경 구성: 723. C# / Visual C++ - Control Flow Guard (CFG) 활성화 [1]파일 다운로드2
13730정성태9/10/20246431오류 유형: 922. docker - RULE_APPEND failed (No such file or directory): rule in chain DOCKER
13729정성태9/9/20247179C/C++: 173. Windows / C++ - AllocConsole로 할당한 콘솔과 CRT 함수 연동 [1]파일 다운로드1
13728정성태9/7/20246998C/C++: 172. Windows - C 런타임에서 STARTUPINFO의 cbReserved2, lpReserved2 멤버를 사용하는 이유파일 다운로드1
13727정성태9/6/20247537개발 환경 구성: 722. ARM 플랫폼 빌드를 위한 미니 PC(?) - Khadas VIM4 [1]
13726정성태9/5/20247434C/C++: 171. C/C++ - 윈도우 운영체제에서의 file descriptor와 HANDLE파일 다운로드1
13725정성태9/4/20246176디버깅 기술: 201. WinDbg - sos threads 명령어 실행 시 "Failed to request ThreadStore"
13724정성태9/3/20248029닷넷: 2296. Win32/C# - 자식 프로세스로 HANDLE 상속파일 다운로드1
13723정성태9/2/20248298C/C++: 170. Windows - STARTUPINFO의 cbReserved2, lpReserved2 멤버 사용자 정의파일 다운로드2
13722정성태9/2/20246034C/C++: 169. C/C++ - CRT(C Runtime) 함수에 의존성이 없는 프로젝트 생성
13721정성태8/30/20246063C/C++: 168. Visual C++ CRT(C Runtime DLL: msvcr...dll)에 대한 의존성 제거 - 두 번째 이야기
13720정성태8/29/20246221VS.NET IDE: 193. C# - Visual Studio의 자식 프로세스 디버깅
13719정성태8/28/20246372Linux: 79. C++ - pthread_mutexattr_destroy가 없다면 메모리 누수가 발생할까요?
13718정성태8/27/20247458오류 유형: 921. Visual C++ - error C1083: Cannot open include file: 'float.h': No such file or directory [2]
1  2  3  4  5  6  7  [8]  9  10  11  12  13  14  15  ...