Microsoft MVP성태의 닷넷 이야기
.NET Framework: 744. C# 6 - Expression bodied function [링크 복사], [링크+제목 복사]
조회: 2323
글쓴 사람
홈페이지
첨부 파일
 

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을 사용해야 하는가"라고 해야 합니다.




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





[최초 등록일: ]
[최종 수정일: 6/8/2018 ]

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

비밀번호

댓글 쓴 사람
 




1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...
NoWriterDateCnt.TitleFile(s)
11854정성태3/25/2019858VS.NET IDE: 133. IIS Express로 호스팅하는 사이트를 https로 접근하는 방법
11853정성태3/24/20191160개발 환경 구성: 435. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면? - 두 번째 이야기
11852정성태3/20/20191249개발 환경 구성: 434. 존재하지 않는 IP 주소에 대한 Dns.GetHostByAddress/gethostbyaddr/GetNameInfoW 실행이 느리다면?파일 다운로드1
11851정성태3/19/20191442Linux: 8. C# - 리눅스 환경에서 DllImport 대신 라이브러리 동적 로드 처리
11850정성태3/18/20191079.NET Framework: 813. C# async 메서드에서 out/ref/in 유형의 인자를 사용하지 못하는 이유
11849정성태3/18/20191598.NET Framework: 812. pscp.exe 기능을 C#으로 제어하는 방법파일 다운로드1
11848정성태3/17/2019976스크립트: 14. 윈도우 CMD - 파일이 변경된 경우 파일명을 변경해 복사하고 싶다면?
11847정성태3/17/20191678Linux: 7. 리눅스 C/C++ - 공유 라이브러리 동적 로딩 후 export 함수 사용 방법파일 다운로드1
11846정성태3/15/20191512Linux: 6. getenv, setenv가 언어/운영체제마다 호환이 안 되는 문제
11845정성태3/15/20191980Linux: 5. Linux 응용 프로그램의 (C++) so 의존성 줄이기(ReleaseMinDependency) [3]
11844정성태5/22/20191938개발 환경 구성: 434. Visual Studio 2019 - 리눅스 프로젝트를 이용한 공유/실행(so/out) 프로그램 개발 환경 설정 [1]파일 다운로드1
11843정성태3/14/20191057기타: 75. MSDN 웹 사이트를 기본으로 영문 페이지로 열고 싶다면?
11842정성태5/3/20191080개발 환경 구성: 433. 마이크로소프트의 CoreCLR 프로파일러 예제를 Visual Studio CMake로 빌드하는 방법 [1]파일 다운로드1
11841정성태3/13/2019890VS.NET IDE: 132. Visual Studio 2019 - CMake의 컴파일러를 기본 g++에서 clang++로 변경
11840정성태3/13/2019955오류 유형: 526. 윈도우 10 Ubuntu App 환경에서는 USB 외장 하드 접근 불가
11839정성태3/12/20191404디버깅 기술: 124. .NET Core 웹 앱을 호스팅하는 Azure App Services의 프로세스 메모리 덤프 및 windbg 분석 개요 [2]
11838정성태5/9/20192074.NET Framework: 811. (번역글) .NET Internals Cookbook Part 1 - Exceptions, filters and corrupted processes [1]파일 다운로드1
11837정성태10/14/20196770기타: 74. 도서: 시작하세요! C# 7.3 프로그래밍 [10]
11836정성태10/12/20191553오류 유형: 525. Visual Studio 2019 Preview 4/RC - C# 8.0 Missing compiler required member 'System.Range..ctor' [1]
11835정성태3/5/20191702.NET Framework: 810. C# 8.0의 Index/Range 연산자를 .NET Framework에서 사용하는 방법 및 비동기 스트림의 컴파일 방법 [1]파일 다운로드1
11834정성태3/4/20191175개발 환경 구성: 432. Visual Studio 없이 최신 C# (8.0) 컴파일러를 사용하는 방법
11833정성태5/14/20191498개발 환경 구성: 431. Visual Studio 2019 - CMake를 이용한 공유/실행(so/out) 리눅스 프로젝트 설정파일 다운로드1
11832정성태3/4/20191184오류 유형: 524. Visual Studio CMake - rsync: connection unexpectedly closed
11831정성태3/4/2019936오류 유형: 523. Visual Studio 2019 - 새 창으로 뜬 윈도우를 닫을 때 비정상 종료
11830정성태2/26/2019876오류 유형: 522. 이벤트 로그 - Error opening event log file State. Log will not be processed. Return code from OpenEventLog is 87.
11829정성태12/12/20191015개발 환경 구성: 430. 마이크로소프트의 CoreCLR 프로파일러 예제 빌드 방법 - 리눅스 환경 [1]
1  2  3  4  5  6  7  8  9  10  11  12  13  14  [15]  ...