C 17의 `constexpr if (false)` 블록에서 정적 어설션이 실패하는 이유는 무엇입니까?

Constexpr If (False) 블록에서 실패한 Static_Assert 동작

C 17에 constexpr if를 도입하면 static_asserts 동작에 대한 우려가 높아졌습니다. 이들 중 촬영되지 않은 지점 내에서

C 표준에 따르면 constexpr if 문이 템플릿 엔터티에 나타날 때 가져오지 않은 분기 내에서 삭제된 문은 인스턴스화되지 않습니다. 이 규칙은 템플릿 인스턴스화 중에 독립적인 false 조건으로 static_asserts의 실행을 금지하여 효과적으로 프로그램의 형식이 잘못된 것으로 간주합니다.

이 동작은 모든 템플릿에 적용되는 보다 일반적인 규칙에서 비롯됩니다. 유효한 전문화를 생성할 수 없는 경우 constexpr에 하위 명령문이 있는 템플릿의 경우 false로 평가되면 템플릿이 올바른지 여부에 관계없이 프로그램은 형식이 잘못된 것으로 간주됩니다.

예를 들어 다음 코드는 최신 버전의 Clang을 사용하여 경고 없이 컴파일되기는 하지만 형식이 잘못되었습니다.

template< typename T>
constexpr void other_library_foo(){
    static_assert(std::is_same<T,int>::value);
}

template<class T>
void g() {
  if constexpr (false)
    other_library_foo<T>(); 
}

이 동작은 static_asserts에 대한 간접 호출로 확장됩니다. constexpr(템플릿) 함수에 종속되지 않은 false 조건이 있는 static_assert가 포함되어 있는 경우 별도의 템플릿 내에서도 constexpr if 문의 사용되지 않은 분기 내에서 호출할 수 없습니다.

의미 및 예방 조치

constexpr if (false) 블록 내 static_asserts에 대한 이러한 제한은 안전성과 유용성에 영향을 미칠 수 있습니다. SFINAE를 대체하는 경우 constexpr을 사용합니다. 개발자는 해당 문의 non-taken 분기 내에서 간접적으로 호출될 수 있는 함수 또는 라이브러리에서 static_asserts의 잠재적 사용을 알고 있어야 합니다.

따라서 다음과 같은 코드에서는 static_asserts 사용을 피하는 것이 좋습니다. constexpr if (false) 블록의 일부로 실행됩니다. 이렇게 하면 프로그램이 올바른 형식으로 유지되고 잠재적인 컴파일러 경고나 오류를 방지할 수 있습니다.

위 내용은 C 17의 `constexpr if (false)` 블록에서 정적 어설션이 실패하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!