개념으로 C++ 템플릿 간소화

♪ ♪

안녕하세요, Alex입니다 Developer Tools 담당이죠 오늘은 Xcode 14에서 지원하는 새 C++20 기능을 소개해 드릴게요 특히 C++20의 개념이 어떻게 generic C++코드의 타입 안전성을 단순화하고 개선하는지에 중점을 둬볼까 합니다 지금부터 이 개념을 사용하는 방법과 여러분만의 개념을 만드는 방법도 설명해 드릴게요 그다음 Xcode에서 지원하는 몇몇 새 C++20 기능을 소개해 드리면서 이야기를 마무리 짓고 일부 기능을 사용하여 컴파일 타임 코드 평가를 통해 C++ 프로젝트의 성능을 향상시키는 방법도 설명해 드리겠습니다

우선 C++의 개념을 알아보기 전에 C++ 일반 코드 작성법을 간단히 살펴볼게요 숫자가 홀수인지 확인하는 함수를 작성하고 싶다고 가정하겠습니다 'int' 매개변수를 받는 함수를 작성할 수 있죠 'int' 타입으로 나타낼 수 있는 모든 값과 함께 작동합니다 부호 없는 64비트 integer값을 여기에 전달하면 어떻게 될까요? 이와 같은 구체적인 함수는 'int' 타입에 맞게 truncate하므로 64비트값으로는 올바르게 작동하지 않아요 하지만 이 문제는 'isOdd'를 함수 템플릿으로 만들면 해결되죠 이제 함수 템플릿이 있으니 부호 없는 64비트 integer값을 전달할 수 있죠 이제 컴파일러는 'uint64_t' 타입과 제대로 작동하는 'isOdd'의 전문화를 자동으로 생성하게 됩니다 이건 다른 두 타입에서 작동하는 두 'isOdd'를 만들 필요가 없음을 의미하기 때문에 정말 유용한 방법이에요 C++ 템플릿을 쓰면 'isOdd' 같은 일반 함수나 컨테이너 클래스도 작성할 수 있습니다 이제 'isOdd'가 어떻게 사용되는지 살펴볼 텐데요 이 함수는 테스트 파일에 추가한 여러 케이스를 통해 확인됐습니다 안타깝게도 제가 그 테스트 중 하나에 실수를 해버렸어요 다행이 컴파일러가 제 실수를 잡아냈지만 컴파일러는 제가 실수한 위치를 가리키는 대신 'isOdd' 템플릿 내부에 오류를 표시하고 있죠 살펴보니 제가 오타를 내서 11 대신 1.1을 입력했군요 그래서 컴파일러가 'double' 타입을 취하는 'isOdd'의 전문화를 생성하게 된 거예요 안타깝게도 잘못된 타입으로 'isOdd'가 호출된 특정 위치를 Xcode가 알려주지 않았기 때문에 이 오타를 찾는 데 시간이 좀 걸렸습니다

언어와 컴파일러는 이런 실수를 빨리 찾을 수 있게 도와줄까요? 글쎄요, 현재 예시에는 어떤 타입이 'isOdd'에 허용되는지에 대한 요구 사항이 명시적으로 나와 있지는 않아요 여기에는 integer 타입을 사용하여 isOdd를 호출해야 한다는 내용의 코멘트만 있죠 C++20 이전에는 프로그래머가 일반 C++ 코드를 작성할 때 템플릿 요구 사항을 지정할 괜찮은 방법이 없었습니다 그래서 템플릿 요구 사항을 지정할 때 코멘트나 특정 매개변수 이름 또는 복잡한 enable_if 검사에 의존해야 했죠 아마 여러분도 들어보셨겠지만 C++20에는 '개념'이라는 새로운 C++ 기능이 도입되었는데 이 개념을 통해 일반 C++ 코드에서 템플릿 요구 사항 확인이 가능해요 그럼 이 개념이 'isOdd'에 전달 가능한 타입의 유효성 검사에 어떻게 도움이 되는지 살펴보겠습니다 먼저 'isOdd' 선언으로 돌아가 볼게요 지금 저는 'class' 키워드를 사용하여 이 템플릿에서 쓰이는 'T' 타입은 모든 타입이 가능하다고 지정했죠 C++20에서는 '클래스' 키워드 대신 개념을 사용하여 템플릿과 함께 사용할 수 있는 타입 집합을 제한할 수 있어요 표준 라이브러리에서 제공하는 'integral' 개념을 사용하여 이 'isOdd' 함수 템플릿을 내장된 integer 타입으로 제한이 가능한데 T가 이 개념을 충족하지 않을 경우 컴파일러는 이 함수 템플릿을 전문화하지 않습니다 적분 개념은 C++ 표준 라이브러리에 선언되어 있어요 그러니 제 코드에서 이걸 쓰려면 개념 헤더를 포함해야겠죠 이제 'isOdd' 함수 템플릿의 type _T_에 'integral' 요구사항을 추가했으니 컴파일러는 테스트에서의 제 실수를 바로 가리키는 훨씬 더 명확한 진단을 제공할 수 있을 거예요 확인해 보니 '1.1'은 더블이므로 'integral' 개념을 만족하지 않는군요 컴파일러는 이 오타를 이전보다 빨리 찾고 수정할 수 있도록 명확한 오류 메시지로 이를 설명할 수 있습니다 버그를 수정하는 데 도움이 될 뿐만 아니라 'isOdd'에 전달된 타입을 제한하면 제가 갖고 있는 모든 테스트 케이스가 integer 타입에서만 작동하는 'isOdd'라고 안심할 수 있죠 그건 알고리즘의 의도된 동작을 테스트한다는 뜻이기도 합니다 개념을 사용하면 템플릿이 사용되는 타입의 intent도 선언할 수 있어요 그런 다음 컴파일러는 템플릿이 전문화되기 전에 타입 요구 사항을 확인합니다 이번엔 개념을 어떻게 사용할 수 있는지 C++ 표준 라이브러리에서 어떤 핵심 개념을 제공하는지 볼게요 C++ 표준 라이브러리는 개념 라이브러리를 제공하죠 타입의 핵심 동작을 확인하는 데 사용할 수 있는 핵심 언어 개념 집합을 구현합니다 코드에 개념 헤더를 포함하면 라이브러리 액세스가 가능하죠

이전 예시에서 이미 'integral' 개념의 사용법을 보여드렸으니 이젠 이 라이브러리에서 제공하는 다른 개념도 살펴볼게요 이 라이브러리는 타입이 내장된 것인지 테스트하는 등의 여러 가지 유용한 핵심 언어 개념을 제공합니다 가령 'floating_point' 개념은 'float' 및 'double'과 같은 내장형 타입으로 충족되죠 여기에 표시된 'static_assert'는 이 케이스가 사실인지 확인합니다 더불어 타입이 constructible한지 destructible한지 변환 가능한지 또는 다른 타입과 동일한지 확인할 수 있는 다른 유용한 핵심 개념을 제공하죠 예를 들어 'convertible_to' 개념은 어느 한 타입이 다른 타입으로 변환 가능한지 테스트합니다 또한 'move_constructible' 개념은 같은 타입의 다른 값에서 직접 구성할 수 있는 타입에 의해 충족되죠 이 라이브러리는 다른 타입과 비교할 수 있는지 테스트하는 몇 가지 비교 개념도 제공해요 'equality_comparable' 개념은 동일 타입의 값으로 작동하는 유효한 '==' 연산자가 있는 타입에 의해 충족된다고 할 수 있어요

이 슬라이드에서 언급한 개념 외에도 이 라이브러리는 기타 여러 핵심 언어 개념을 제공합니다 또한 타입의 이동, 복사가 되는지 테스트하는 개념을 제공하죠 그 외에도 타입이 호출 가능한 개체인지 확인하는 개념도 제공해요

이제 C++ 표준 라이브러리에서 제공하는 개념을 살펴보았으니 개념을 사용하여 템플릿을 제한하는 방법을 알아볼게요 보신 것처럼 템플릿에서 클래스 키워드 대신 개념을 사용하여 이 템플릿에 허용되는 타입을 제한할 수 있습니다 그 외에도 여러 개념으로 타입을 제한해야 하는 경우에는 템플릿 선언에서 'requires' 절을 사용할 수 있어요 그 방법을 알아보기 위해 약간 다른 예시를 보도록 하죠

여길 보시면 'isDefaultValue' 함수 템플릿이 있습니다 주어진 값이 해당 타입의 기본값과 같으면 true를 반환하게 되죠 이 템플릿이 전문화되기 전에 이 타입이 이러한 작업을 지원하는지 테스트하려면 표준 라이브러리의 두 개념을 쓰면 돼요 그리고 이 함수 템플릿에 허용되는 타입 집합을 제한하기 위해 'requires' 절을 추가할게요 개념 라이브러리의 어떤 개념이 타입 검증에 도움이 되는지 한번 살펴보겠습니다 'equality_compar ble' 개념은 _T_가 동일한 타입의 다른 값과 비교할 수 있는지를 테스트합니다 그다음 'default_construct ble' 개념은 _T_가 기본 생성자가 있는 타입인지 테스트합니다 여기에서 논리 연산자 AND는 컴파일러에게 두 개념의 유효성을 검사하도록 지시하죠 이렇게 하면 이 함수 템플릿이 지원되는 타입으로만 전문화될 수 있어요 이제 지금까지 배운 내용을 다시 짚고 넘어갈 볼게요 템플릿에서 사용할 수 있는 타입을 제한하려면 개념을 사용해야 해요 만약 타입 불일치가 발생한다면 템플릿을 전문화할 필요가 없으므로 컴파일러는 더 명확한 진단을 표시할 수 있죠 타입의 일부 핵심 동작을 검증해야 하는 경우에는 개념 라이브러리의 개념을 재사용해야 하고

타입이 여러 요구 사항을 준수하나 테스트해야 한다면 템플릿에 'requires' 절을 추가해야 합니다 우린 C++ 프로그램에서 개념을 사용하는 방법도 살펴봤죠 C++를 사용하면 타입의 특정 동작을 검증하는 사용자 정의 개념을 선언할 수 있어요 다음으로는 특정 타입 동작의 유효성을 검사하는 여러분만의 개념을 만드는 방법을 살펴볼게요 하지만 먼저 선언하려는 개념에 의해 검증되어야 하는 동작 요구 사항을 식별하는 방법을 살펴볼 필요가 있겠네요 이번에는 개념을 사용하여 특정 타입 동작의 유효성을 검사하는 방법을 설명하기 위해 새로운 예시를 보여드릴게요 다양한 2차원 모양을 이미지로 렌더링할 수 있는 C++ 라이브러리를 구축 중이라고 가정해 보겠습니다

전 제 라이브러리에서 다양한 모양을 지원하고 싶은데요 우선 가장 간단하게 렌더링 가능한 원형 모양으로 시작해 볼게요 C++ 클래스를 사용하여 위치 및 반경과 같은 속성을 저장하고 원을 렌더링하기 위해 렌더링 이미지의 각 픽셀에서 실행되는 거리 함수 기반의 렌더링 알고리즘을 사용하겠습니다 이 알고리즘은 모양을 렌더링하기 위해서 모양의 표면까지의 거리를 계산해야 합니다 Circle 클래스 'getDistanceFrom' 메서드가 이를 계산하고 원 내부의 음수 거리와 원 외부의 양수 거리를 반환합니다 원 외에도 다른 모양을 렌더링할 수 있어요 예를 들어 다른 원 모양에서 하나의 원 모양을 기하학적으로 뺀 다음 초승달 모양을 렌더링할 수도 있죠 이제 클래스를 사용하여 렌더링하고 싶은 초승달 모양을 나타내 볼게요 각각의 새로운 모양 클래스에는 'getDistanceFrom' 메서드가 있죠 여러 모양 클래스를 만든 다음 이제 이러한 모양을 렌더링하여 잘 구현이 됐는지 확인해 볼게요 어떤 모양과도 작동하는 렌더링 함수를 만드는 방법에는 여러 가지가 있어요 모양에 대한 클래스 계층을 만들고 가상 메서드를 써서 표면까지 거리를 계산할 수 있죠 하지만 이 함수는 렌더링 중 수백만 번 호출될 테니 가상 호출 오버헤드를 피하기 위해 함수 템플릿을 대신 사용하도록 할게요 그래서 제가 이 렌더링 함수 템플릿을 만든 거예요 computePixelColor 함수는 모양값을 가져와서 주어진 픽셀이 모양 안에 있는지 확인하고 만약 안에 있다면 흰색으로 반환하게 되죠 그럼 이제 도형을 올바르게 채울 수 있는지 확인할 수 있어요

이 함수는 원형, 초승달 또는 다른 일치하는 타입과 같은 모든 모양 타입과 함께 작동하도록 하는 템플릿이에요 여기에서는 템플릿이 잘 작동하지만 저는 개념을 사용하여 이 함수에 전달할 수 있는 타입을 제한해 보고 싶습니다 이 함수에 전달되는 타입을 제한하면 타입 불일치 발생 시 컴파일러에서 보다 명확한 진단이 가능합니다 그 외에도 이 함수에 전달되는 타입을 제한하면 이 함수의 추가 오버로드를 더할 수도 있죠

이제 타입을 제한하기 위해 Shape 개념을 만들어 볼게요 이 개념은 타입의 동작을 확인하고 원, 초승달 그리고 향후 추가할 수 있는 다른 모양 클래스를 허용하기도 합니다 'Shape'와 같은 개념을 만들려면 먼저 이 개념에 의해 검증되어야 하는 요구 사항을 식별해야 해요 어떻게 하는지 같이 한번 볼게요 이 함수 템플릿은 'T' 타입을 일반 타입으로 사용합니다 그다음 'T' 타입 'shape' 인수가 이 함수에 전달되죠 그다음 'getDistanceFrom' 메서드를 호출할 때 'shape' 인수가 함수 내에서 사용됩니다 보시다시피 이 함수의 모양에 대해서는 다른 작업이 수행되지 않기 때문에 이건 제 개념에서 확인하려는 유일한 요구사항이라 할 수 있어요 이제 'requires' 표현식으로 타입이 특정 방식으로 동작하는지 테스트할 수 있습니다 그럼 'requires'를 사용하여 Shape 개념 만드는 법을 보죠 이제 전 'requires' 내에서 타입의 동작을 테스트하는 표현식 세트를 제공해야 하는데요 테스트해야 하는 단일 요구 사항으로 'getDistanceFrom'에 대한 호출을 이미 식별했으니 이제 ' Shape' 개념을 만들 수 있어요 이번엔 'concept' 키워드를 써서 모양 개념을 선언했어요 그다음 타입 유효성 검사를 위해 'requires' 표현식을 더하고 'requires' 표현식에 인수 목록도 추가했어요 이 인수 목록을 통해 'requires' 내에서 테스트할 'T' 타입의 값 'shape'를 선언할 수 있죠 표현식에서 인수 목록을 써서 모든 타입의 값 선언이 가능합니다 이제 요구 사항 내에서 이러한 값을 사용할 수 있어요 'requires' 표현식의 본문에는 이 개념이 충족되기 위해 필요한 일련의 요구 사항이 포함되어 있어요 'shape'의 개념엔 간단한 표현식 요구 사항이 하나 있습니다 'getDistanceFrom'에 대한 메서드 호출 유효성 확인이죠 이 표현식은 실제로 프로그램에서 실행되지 않아요 타입의 동작을 확인하기 위해서는 컴파일 타임에만 필요하며 확인 후에는 삭제됩니다 표현식 요구 사항을 사용하여 특정 표현식이 컴파일되는지 여부를 테스트하면 타입의 동작을 검증할 수 있죠 이 표현식은 'getDistanceFrom' 메서드 호출에 대한 인수가 누락되었기 때문에 아직 완전하다고 볼 수 없어요 이 메서드는 'float' 타입의 두 값을 사용하기 때문에 floating point literal 둘을 써서 이 표현식을 완성할 수 있어요 이제 'getDistanceFrom' 메서드가 제 일반 코드에서 가정하는 float값을 반환하는지 테스트하기 위해 추가 검사를 해 볼게요 현재는 형식에 'getDistanceFrom' 메서드가 있는지 테스트하기 위해 간단한 표현식 요구사항을 사용하고 있어요 하지만 표현식 요구사항 대신 compound 요구사항을 사용하여 float값을 반환하는지 테스트할 수도 있죠 화살표 연산자는 compound 요구 사항을 따를 수 있어요 화살표 연산자는 오른쪽에 제약 조건을 기대하기 때문에 'getDistanceFrom' 메서드 호출이 float값을 반환하는지 확인하려면 'same_as'와 같은 표준 라이브러리 개념을 사용할 수 있죠 이제 이 개념은 준비가 다 된 것 같네요

이건 'computePixelColor' 함수에 전달할 수 있는 타입을 제한하는 데 사용할 수도 있어요 이제 제 일반 'computePixelColor' 함수는 'Shape' 개념을 충족하는 타입에서만 작동합니다 Circle 및 Crescent 같은 클래스가 이 특정 일반 'computePixelColor' 함수를 사용하여 렌더링된다는 뜻이죠 이런 타입이 모두 'Shape' 개념을 충족하거든요

기본 모양이 렌더링된 것을 확인하고 나서 이제는 일부 모양에 색상을 추가하는 'computePixelColor'의 다른 버전을 만들고 싶은데요 제 모양 라이브러리에 다채로운 GradientCircle 클래스를 더할게요 이제 이미지의 픽셀 색상을 계산하는 새 함수가 필요한데 C++20를 사용하면 'computePixelColor' 함수 템플릿의 여러 변형을 만들 수 있어요 각 변형은 다른 개념을 사용하여 제한되어야 하는데 전 GradientCircle과 같은 클래스에서 만족할 새로운 GradientShape 개념을 만들어 볼게요 그럼 이 개념은 그레이디언트가 있는 모양에서만 작동하는 'computePixelColor'의 새로운 변형을 제한하게 되죠 이것은 Shape 개념과 마찬가지로 'requires' 표현식을 사용하여 구현됩니다 하지만 GradientShape가 원래의 Shape 개념도 만족해야 하므로 새로운 개념의 첫 번째 요구 사항을 포함해야 해요 이렇게 하면 GradientShape 개념을 만족하는 클래스가 Shape 개념도 만족하게 되니 해당 클래스의 값에 대해 'getDistanceFrom' 메서드를 계속 호출할 수 있죠 그런 다음 논리 연산자와 'requires' 표현식을 사용하여 GradientShape 개념이 'getGradientColor' 메서드가 있는 클래스에서만 충족될 수 있도록 설정합니다 이제 GradientShape 개념을 만들었으니 'computePixelColor'의 새로운 변형도 만들 수 있겠네요 이 함수 템플릿은 GradientShape 개념에 의해 제한되므로 GradientCircle 클래스처럼 그레이디언트가 있는 모양 클래스에서만 작동해요 이제 모든 조각이 제자리에 있으니 계속하여 그레이디언트로 원을 렌더링할 수 있겠네요 지금 여기서 GradientCircle을 렌더링하고 있는데요 이제 컴파일러가 'render' 함수 내부에서 어떤 'computePixelColor'의 오버로드를 선택하는지 볼게요

computePixelColor의 두 변형은 GradientCircle과 사용 가능하지만 컴파일러는 첫 번째 오버로드보다 더 구체적이기 때문에 GradientShape 개념으로 제한되는 오버로드를 선택하게 됩니다 컴파일러는 'computePixelColor'와 가장 일치하는 오버로드를 택하니 테스트 때 아름다운 그러데이션 원을 볼 수 있을 거예요 엄청나죠!

이제 개념 생성에 대해 배운 내용을 다시 짚어 볼게요

기존 일반 코드에서 동작 요구 사항을 식별하여 개념을 만들 수 있고 타입의 동작을 검증하기 위한 개념을 작성하려면 요구 표현식을 사용해야 하죠 개념을 사용하면 일반 함수 및 클래스의 보다 구체적인 변형도 가능합니다

개념을 사용하여 일반 C++ 코드를 향상시키는 방법을 살펴봤는데요 지원 개념 외에도 Xcode 14은 다른 C++20 기능에 대한 지원도 향상시켰어요 더 구체적으로 설명하자면 컴파일 타임 C++ 코드 평가에 대한 지원 향상을 강조하고 싶네요 컴파일 타임 코드 평가는 C++ 코드의 변수 초기화 비용을 줄일 수 있기 때문에 유용한 기능이라 할 수 있어요 복잡한 초기화 시퀀스에 의존하는 C++ 코드가 앱에 많다면 앱 시작 시간을 줄이는 데 도움이 될 수 있죠 그 외에도 컴파일 타임 코드 평가는 컴파일 타임에 검증이 필요한 상수를 검증하는 데 도움이 될 수 있어요 코드가 실행되기 전에 버그를 잡는 데도 도움이 되죠 이제 C++에서 컴파일 타임 코드 평가를 사용하는 방법을 알아보기 위해 예시를 살펴볼게요

여기에는 제 모양 렌더링 라이브러리에서 색상 팔레트를 초기화하는 코드 스니펫이 있는데요 이건 모양을 디스플레이에 렌더링하는 iOS 앱에서 사용됩니다 팔레트의 각 색상은 색상의 HTML 16진수 코드로 string literal을 구문 분석 하여 초기화됩니다 우선 'fromHexCode' 함수는 배열을 초기화하는 동안 세 개의 string literal을 구문 분석 해야 해요 이와 같이 복잡한 상수 초기화 작업은 상수가 많을수록 앱의 시작 시간에 눈에 띄는 영향을 줄 수 있습니다 대신 이 배열이 일정한 색상값으로 초기화되도록 컴파일 타임 코드 평가를 사용할 수 있죠 어떻게 하는 건지 한번 보여드릴게요 'constexpr' 키워드는 C++ 컴파일 타임 코드 평가를 활성화합니다 팔레트가 일정한 색상 배열이 되도록 하기 위해서는 예시의 여러 위치에 추가해야 하죠 먼저 'fromHexCode' 함수에 'constexpr' 키워드를 추가해요 컴파일러는 이제 컴파일 타임 초기화 시퀀스에서 사용되는 컴파일 타임에 이 함수의 코드를 실행할 수 있어요 컴파일 타임에 평가하려면 C++ 함수를 'constexpr'로 만들어야 합니다 컴파일러는 'constexpr' 초기화 시퀀스에서 오류를 표시하여 이러한 함수의 코드를 컴파일 시간에 평가할 수 없다는 것을 알려줍니다 하지만 'constexpr'을 추가하기 전에 함수를 검사하여 컴파일 시간에 평가할 수 있는지도 확인할 수 있죠 이번에는 fromHexCode를 살펴보고 이와 같은 함수가 컴파일 타임 코드 평가를 위한 좋은 선택이 될 수 있을지 확인하는 방법을 알아볼게요 이 함수는 if 문처럼 언어 구성과 비교 연산자 및 산술 연산자와 같은 기본 연산을 사용해요 이러한 모든 작업은 컴파일 타임에 평가될 수 있죠 또한 이 함수는 다른 함수인 hexToInt를 여러 번 호출해요 이미 hexToInt 함수에 'constexpr' 주석을 달았으니 이 함수에 대한 호출은 컴파일 타임에 평가될 거예요 전반적으로 fromHexCode에는 컴파일러가 컴파일 시간에 평가할 수 있는 코드가 포함되어 있기 때문에 컴파일 시간 초기화 시퀀스에서 진행하고 사용하는 것이 안전하죠 이어 fromHexCode가 컴파일 시간에 평가될 수 있는지 확인한 다음 'colorPalette' 변수 선언에 'constexpr' 키워드를 추가해야 합니다 이제 컴파일러는 컴파일 타임에 이 배열의 전체 초기화 시퀀스를 평가하게 될 거예요 더 명확히 말하자면 컴파일러는 fromHexCode 함수에 대한 각 호출을 평가한다고 볼 수 있죠 평가는 팔레트의 이니셜라이저에 있는 함수에 대한 원래 호출을 대체할 상수 색상값을 생성하게 됩니다 fromHexCode에 대한 모든 호출이 상수 색상값으로 대체되었으니 이제 'colorPalette' 변수는 상수 색상값을 포함하는 array literal로 초기화되죠 제 앱이 이 팔레트가 초기화될 때 이제는 색상값을 parsing하기 위해 추가적인 비용이 들지 않는다는 것을 의미하기도 해요 이것은 앱 내부의 이 C++ 라이브러리가 시작할 때 수행해야 하는 작업의 양을 줄이기 때문에 앱의 시작 시간에도 도움이 되죠 그리고 상수값으로 초기화되도록 하려면 C++ 변수를 'constexpr'로 만들어야 하는데 Xcode 14은 실제로 컴파일 시간 평가를 위한 표준 라이브러리 지원을 크게 개선했어요 올해 우리는 여러 표준 라이브러리 타입 및 알고리즘에 'constexpr' 지원을 추가했고 이제 이를 컴파일 타임 코드 평가 중에도 사용할 수 있게 되었습니다

그 외에도 Xcode 14은 C++20 표준 지원을 대폭 개선했는데요 이제 C++20 모드에서 여기 표시된 모든 함수를 사용할 수 있어요

아직 C++20 모드로 안 바꾸었다면 오늘 바로 바꿔보세요 Xcode 프로젝트에서 'C++ Language Dialect'를 보면 C++20로 업그레이드할 수 있어요 C++20로 바꾸면 코드에서 개념과 같은 기능을 쓸 수 있죠 C++20에는 최소 배포 대상이 필요하지 않기 때문에 현재 대상으로 하는 동일한 OS 버전에 대한 코드를 계속 ship할 수 있습니다 지금 바로 C++20를 사용해 보세요 감사합니다 다른 개발자 컨퍼런스도 꼭 확인해 보시길 바라요