C++20에서 사용되는 부동 소수점 값을 비유형 템플릿 인수로 간주할 때에 동등성을 결정하기 위해 적용되는 특정 비트 수준 비교 규칙은 무엇이며, 왜 -0.0과 +0.0은 런타임 표현식에서 동등하게 비교되지만 별도의 템플릿 인스턴스를 생성합니까?

질문에 대한 답변

C++20은 부동 소수점 유형을 비유형 템플릿 매개변수(NTTP)로 도입하면서 이를 구조적 유형으로 분류했습니다. 표준([temp.type]/4)에 따르면 두 개의 비유형 템플릿 인수는 오직 동일할 때만 일치합니다. 부동 소수점 값의 경우 동등성은 값의 동등성보다는 비트 단위의 동일성에 의해 결정됩니다. 이는 두 개의 부동 소수점 상수가 동일한 템플릿 인수로 간주되려면 객체 표현이 완전히 일치해야 함을 의미합니다(모든 비트가 일치해야 합니다).

따라서 IEEE 754 표현에서 부호 비트만 다르기 때문에 +0.0과 -0.0은 별개의 템플릿을 인스턴스화합니다. 유사하게 서로 다른 NaN 페이로드는 서로 다른 유형을 생성합니다. 이는 런타임 동작과 극명하게 대조되며, 여기서 +0.0 == -0.0은 true로 평가됩니다. 이는 동등성 연산자가 수학적 동등성을 구현하지만 템플릿 메커니즘은 물리적 동일성을 요구하기 때문입니다.

실생활의 상황

우리는 물리 시뮬레이션 엔진을 위한 컴파일 타임 차원 분석 라이브러리를 구축하는 동안 이 문제를 만났습니다. 우리는 물리 상수(예: 중력 상수)를 표현하기 위해 double NTTP를 사용했고, 이론적으로 질량이 0인 경우(0.0으로 표현됨)에 대한 솔버를 전문화하고 싶었습니다. 그러나 질량 중심을 평가하는 일부 constexpr 계산에서 특정 산술 작업(예: -1.0 * 0.0)에 의해 -0.0이 생성되었습니다.

사용자가 이러한 계산 결과를 템플릿 인수로 전달했을 때, 컴파일러는 우리의 ZeroMass 전문화가 아닌 일반 구현을 선택하여 전반적으로 40% 성능 저하를 초래했습니다. 일반 버전은 단위 행렬을 반환하는 대신 전체 행렬 역을 수행했습니다.

우리는 세 가지 솔루션을 고려했습니다. 첫째, +0.0과 -0.0 모두에 대해 명시적으로 전문화할 수 있었습니다. 이 방법은 올바른 동작을 보장했지만 유지 관리 부담이 두 배로 증가하고 다양한 NaN 표현이나 반올림 오류로 인한 다른 비트 패턴을 가진 사실상 0인 값을 처리할 수 없었습니다.

둘째, 부호 비트를 0으로 강제 설정하는 constexpr 헬퍼 함수를 사용하여 모든 입력을 정규화하는 것을 고려했습니다(예: value == 0.0 ? 0.0 : value). 이 솔루션은 0에 대해 강력했지만 모든 템플릿 인스턴스 주위에 래퍼 매크로가 필요하여 API를 오염시키고 사용자가 직접 매개변수 전달을 기대하는 데 혼란을 주었습니다.

셋째, if constexpr 및 std::bit_cast를 사용하여 메타 함수의 진입 지점에서 값을 정규화하는 유형 정규화 계층을 구현했습니다. 이렇게 하면 모든 0을 양수로 취급하고 조용한 NaN을 정규화된 페이로드로 축소합니다. 우리는 이 솔루션을 선택했는데, 이는 라이브러리 사용자에게 투명성을 제공하면서 내부 일관성을 보장했기 때문입니다.

구현 후, 라이브러리가 모든 부동 소수점 NTTP를 비트 표현으로 처리한다고 문서화했습니다. 이는 성능 문제를 해결했지만 개발자들이 -0.0과 +0.0이 유형 시스템에서 별개의 구성 상태라는 것을 인지해야 했습니다.

후보자가 자주 놓치는 것

std::is_same_v<decltype(func<+0.0>()), decltype(func<-0.0>())>가 true인 +0.0 == -0.0일 때 false로 평가되는 이유는 무엇입니까? 템플릿 인스턴스화는 단일 정의 규칙(One Definition Rule)과 정확한 템플릿 인수 일치에 의존합니다. 컴파일러가 func<+0.0>()를 만났을 때, 부동 소수점 리터럴의 비트 패턴을 해싱하거나 비교합니다. IEEE 754는 -0.0의 부호 비트가 설정되어 있고 +0.0은 설정되어 있지 않다고 명시하므로, 컴파일러는 서로 다른 상수 값을 보고 두 개의 별개의 함수 인스턴스를 생성합니다. 런타임에서의 동등성 연산자는 IEEE 754 사양을 구현하여 서명된 0이 같다고 비교하지만 템플릿 기계는 런타임 의미론이 적용되기 전에 객체 표현 수준에서 작동합니다. 후보자는 값이 수학적으로 동등하므로 동일한 유형을 생성해야 한다고 가정하는 경우가 많으며, 런타임 값 의미론과 컴파일 타임 유형 동등성을 혼동합니다.

template<float F> struct S{}; S<1.0>가 정상 표현에서는 float로 암묵적으로 변환될 수 있지만 컴파일에 실패하는 이유는 무엇입니까? 부동 소수점 유형의 비유형 템플릿 매개변수에 대해 C++20 표준은 템플릿 인수가 매개변수와 동일한 유형이어야 한다고 명시합니다. 표준 부동 소수점 프로모션 및 변환은 허용되지 않습니다([temp.arg.nontype]/5). 리터럴 1.0은 유형이 double이고 float가 아니므로 float F에 직접 바인딩될 수 없습니다. float 접미사를 사용해야 합니다: S<1.0f>. 이 제한은 템플릿 망칠(mangling)과 유형 동등성이 변환 정밀도 손실 없이 모호하지 않은 표현을 요구하기 때문에 존재합니다. 초보자들은 함수 호출이 변환을 허용하지만 템플릿은 변환 규칙이 고려되기 전에 정확한 유형 일치를 수행하기 때문에 이 점을 자주 놓칩니다.

다른 조용한 NaN(qNaN) 페이로드가 모든 "숫자가 아님"을 나타내는 동안 템플릿 인스턴스화에 어떻게 영향을 미칩니까? IEEE 754는 NaN 값이 페이로드 비트를 가질 수 있도록 허용합니다(진단 정보). C++20 템플릿 동등성이 비트 단위 비교를 사용하므로 서로 다른 페이로드를 가진 두 NaN(예: std::numeric_limits<double>::quiet_NaN()와 서로 다른 하드웨어에서의 0.0/0.0의 결과)은 별개의 템플릿 인수입니다. 이는 코드 경로가 여러 NaN 비트 패턴에 대한 템플릿을 인스턴스화하면 코드 증가를 초래하거나 프로그래머가 단일 전문화라고 가정한 다른 번역 단위에서 서로 다른 NaN 표현을 관찰할 경우 미세한 ODR 위반을 초래할 수 있습니다. 후보자들은 종종 NaN이 nullptr와 같은 단일 값이라고 가정하지만 실제로는 각기 다른 비트 패턴의 범위를 나타내며, 템플릿 시스템에서 각각은 별개입니다.