언리얼 엔진 5 코딩 표준 2 (포터블 C++ 코드 표준 라이브러리 사용)

포터블 C++ 코드

int 및 부호 없는 int 타입은 플랫폼에 따라 크기가 다를 수 있다. 최소 너비는 32비트로 보장되며, 정수 너비가 중요하지 않은 경우라면 코드에서 사용해도 괜찮다. 명시적으로 크기가 정해진 여전히 시리얼라이즈 또는 리플리케이트된 포맷으로 사용된다.

 

주요 타입 목록

bool : 부울 값(부울 크기 추정 금지). BOOL 은 컴파일되지 않습니다.

TCHAR : character(문자) (TCHAR 크기 추정 금지)

uint8 : unsigned byte(부호 없는 바이트) (1바이트)

int8 : signed byte(부호 있는 바이트) (1바이트)

uint16 : unsigned shorts(부호 없는 short) (2바이트)

int16 : signed short(부호 있는 short) (2바이트)

uint32 : unsigned int(부호 없는 int) (4바이트)

int32 : signed int(부호 있는 int) (4바이트)

uint64 : unsigned quad word(부호 없는 쿼드 단어) (8바이트)

int64 : signed quad word(부호 있는 쿼드 단어) (8바이트)

float : 단정밀도 부동 소수점(4바이트)

double : 배정밀도 부동 소수점(8바이트)

PTRINT : 포인터를 가질 수 있는 정수(PTRINT 크기 추정 금지)

 

표준 라이브러리 사용

과거에는 UE에서 아래와 같은 이유로 표준 라이브러리를 직접 사용하는 것을 지양했다

 

1. 느린 구현을 자체 라이브러리로 대체하여 메모리 할당에 대한 제어력 강화

2. 바람직하지만 비표준적인 동작 변경 수행

3. 코드베이스 전체에서 문법 일관성 유지

4. UE 언어와 호환되지 않는 컨스트럭트 방지

 

하지만 표준 라이브러리의 완성도가 높아지면서 추상화 레이어로 래핑하거나 직접 재구현하지 않아도 되는 함수 기능을 포함하게 되었다. 그래서 라이브러리는 더 나은 결과를 제공하는 옵션을 사용하면 되지만 일관성 또한 중요하게 고려해야 한다. 

 

동일한 API에서 UE 언어와 표준 라이브러리 언어를 혼합하여 사용하지 않도록 사용해야 하는데 아래는 일반적인 언어 및 사용 시점에 대한 제안 목록이다.

 

<atomic>

atomic 언어는 새 코드로 사용해야 하며, 터치 시 기존 코드는 이주해야 한다. Atomic은 지원되는 모든 플랫폼에서 완전히 효율적으로 구현되어야 한다. 에픽의 자체 TAtomic 은 부분적으로만 구현되며 에픽에서 이를 유지보수하고 개선할 예정이 없다고 한다.

 

<type_tratis>

type traits 언어는 레거시 UE 특성과 표준 특성 간에 겹치는 부분이 있는 경우 사용해야 한다. 특성은 종종 정확도를 위해 컴파일러 고유 속성으로 구현되며, 컴파일러는 표준 특성을 파악하여 이를 일반 C++로 처리하는 대신 보다 빠른 컴파일 경로를 선택할 수 있다. 한 가지 우려되는 사항은 UE 특성이 보통 Value static 또는 Type typedef를 갖는 반면, 표준 특성은 value 및 type 을 사용하게 되어 있다. 이는 중요한 차이점으로, 컴포지션 특성에 의해 std::conjunction 과 같은 특정 문법이 필요하기 때문이다. 새 특성은 컴포지션을 지원하기 위해 소문자 value 또는 type 으로 작성되어야 합니다. 기존 특성은 대/소문자를 모두 지원하도록 업데이트되어야 한다.

 

<initializer_list>

initializer list 언어는 중괄호로 묶인 이니셜라이저 문법을 지원하기 위해 사용되어야 한다. 이는 언어와 표준 라이브러리가 겹치는 경우에 해당된다. 이를 지원하려는 경우 대안은 없다.

 

<regex>

regex 언어는 직접적으로 사용할 수도 있지만 에디터 전용 코드 내에 캡슐화해서 사용해야 한다. 자체 정규 표현식 솔루션을 구현할 계획은 없다.

 

<limits>

std::numeric_limits 를 온전히 사용할 수 있다.

 

<cmath>

이 헤더의 모든 부동 소수점 함수를 사용할 수 있다.

 

<cstring> : memcpy() 및 memset()

이러한 언어는 명확한 퍼포먼스상의 이점이 있을 경우 각각 FMemory::Memcpy 및 FMemory::Memset 대신 사용할 수 있다.