Microsoft MVP성태의 닷넷 이야기
.NET Framework: 744. C# 6 - Expression bodied function [링크 복사], [링크+제목 복사],
조회: 13662
글쓴 사람
정성태 (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"의 문법에서 사용한 "=>"는 람다 표현식이 아니다, 라고 합니다. 해당 기호에 따른 이후의 코드는 델리게이트나 표현식 트리와 무관하다는 것을 이유로 들고 있으며 단지 읽기 전용의 속성을 생성하라는 문법을 "=>"로 지시하는 역할만 한다고 합니다. 에고... 그동안 해당 구문을 람다 식이라고 제 책에서 써 왔는데, 고쳐야겠습니다. ^^;
정성태

... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...
NoWriterDateCnt.TitleFile(s)
11901정성태5/21/201911963오류 유형: 538. msbuild 오류 - Could not find a part of the path '%LOCALAPPDATA%\Temp\2\.NETFramework,Version=v4.0.AssemblyAttributes.cs'
11900정성태5/18/201911242오류 유형: 537. "sfc /scannow" 실행 중 시스템이 부팅되는 현상
11899정성태5/17/201912246Linux: 9. Linux에서 윈도우의 OutputDebugString 대신 사용할 수 있는 syslog [1]
11898정성태5/16/201913604VC++: 130. C++ string의 c_str과 data 함수의 차이점 [3]
11897정성태5/16/201920175오류 유형: 536. Visual Studio - "Developer Pack"을 설치했는데도 "대상 프레임워크" 목록에 나오지 않는 경우 [2]
11896정성태5/15/201914973개발 환경 구성: 440. C#, C++ - double의 Infinity, NaN 표현 방식파일 다운로드1
11895정성태5/12/201913382.NET Framework: 832. ML.NET Model Builder - 회귀(Regression), 다중 분류(Multi-class classification) 예제파일 다운로드1
11894정성태5/10/201914540VS.NET IDE: 135. Visual Studio - ML.NET Model Builder 소개 [5]
11893정성태5/10/201912250오류 유형: 535. C# 6.0 이상의 문법을 컴파일 시 오류가 발생한다면?
11892정성태5/10/201912284웹: 38. HTTP Cookie의 expires 시간 형식(RFC7231)
11891정성태5/9/201914815.NET Framework: 831. (번역글) .NET Internals Cookbook Part 12 - Memory structure, attributes, handles
11890정성태5/8/201910529개발 환경 구성: 439. "Visual Studio Enterprise is required to execute the test." 메시지와 관련된 코드 기록
11889정성태5/8/201911247개발 환경 구성: 438. mstest, QTAgent의 로그 파일 설정 방법
11888정성태5/8/201926387.NET Framework: 830. C# - 비동기 호출을 취소하는 CancellationToken의 간단한 예제 코드 [1]파일 다운로드1
11887정성태5/8/201913084.NET Framework: 829. C# - yield 문을 사용할 수 있는 메서드의 조건
11886정성태5/7/201912083오류 유형: 534. mstest.exe 실행 시 "Visual Studio Enterprise is required to execute the test." 오류 [2]
11885정성태5/7/20199095오류 유형: 533. mstest.exe 실행 시 "File extension specified '.loadtest' is not a valid test extension." 오류 발생
11884정성태5/5/201912782.NET Framework: 828. C# DLL에서 Win32 C/C++처럼 dllexport 함수를 제공하는 방법 - 두 번째 이야기
11883정성태5/3/201916989.NET Framework: 827. C# - 인터넷 시간 서버로부터 받은 시간을 윈도우에 적용하는 방법파일 다운로드1
11882정성태5/2/201913988.NET Framework: 826. (번역글) .NET Internals Cookbook Part 11 - Various C# riddles파일 다운로드1
11881정성태4/28/201914268오류 유형: 532. .NET Core 프로젝트로 마이그레이션 시 "CS0579 Duplicate 'System.Reflection.AssemblyCompanyAttribute' attribute" 오류 발생
11880정성태4/25/201911043오류 유형: 531. 이벤트 로그 오류 - Task Scheduling Error: m->NextScheduledSPRetry 1547, m->NextScheduledEvent 1547
11879정성태4/24/201916290.NET Framework: 825. (번역글) .NET Internals Cookbook Part 10 - Threads, Tasks, asynchronous code and others파일 다운로드2
11878정성태4/22/201914239.NET Framework: 824. (번역글) .NET Internals Cookbook Part 9 - Finalizers, queues, card tables and other GC stuff파일 다운로드1
11877정성태4/22/201914127.NET Framework: 823. (번역글) .NET Internals Cookbook Part 8 - C# gotchas파일 다운로드1
11876정성태4/21/201913963.NET Framework: 822. (번역글) .NET Internals Cookbook Part 7 - Word tearing, locking and others파일 다운로드1
... 61  62  63  64  65  66  67  68  [69]  70  71  72  73  74  75  ...