C 오버로드 해결에서 포인터 붕괴가 추론된 템플릿보다 우선하는 이유는 무엇입니까?

포인터 붕괴 대 추론된 템플릿: 우선순위 퍼즐 풀기

C 영역에서 함수 오버로드와 템플릿 추론 간의 상호 작용은 다음과 같습니다. 때로는 예상치 못한 결과를 낳기도 합니다. 배열과 원시 포인터를 모두 처리하기 위해 함수가 오버로드되는 경우가 대표적인 예입니다. 다음 코드를 고려하십시오.

template <size_t n>
void foo(const char (&s)[N]) {
    std::cout <p>처음에는 배열의 길이를 인쇄하도록 고안된 이 함수는 비배열을 지원하도록 확장되었습니다. 그러나 이 확장은 수수께끼 같은 모호성을 초래합니다.</p>
<pre class="brush:php;toolbar:false">foo("hello") // now prints raw, size=5

후자가 매개 변수와 더 정확하게 일치함에도 불구하고 의도된 "배열" 버전 대신 "원시" 오버로드가 선택되는 이유는 무엇입니까? 대답은 포인터 붕괴라는 미묘한 개념에 있습니다.

포인터 붕괴는 배열에서 해당 포인터로의 암시적 변환입니다. 이 경우 "hello" 배열은 첫 번째 요소에 대한 const char * 포인터로 자동 변환됩니다. 결과적으로 포인터를 처리하는 오버로드가 우선합니다.

이 동작은 C의 변환 비용에서 비롯됩니다. 인수를 매개변수로 변환하는 비용을 최소화하기 위해 오버로드가 평가됩니다. 이 경우 배열에서 포인터로 변환하는 것이 배열에서 함수 매개변수로 변환하는 것보다 비용이 적게 듭니다.

이 문제를 해결하려면 두 번째 오버로드도 템플릿으로 정의할 수 있습니다.

template <typename t>
auto foo(T s)
-> std::enable_if_t<:is_convertible char const>{}>
{
    std::cout <p>이 접근 방식은 포인터 붕괴 변환을 제거하기 때문에 템플릿 버전이 선호되도록 보장합니다.</p>
<p>결론적으로 추론된 버전보다 포인터 붕괴에 우선순위가 부여됩니다. 템플릿은 과부하 해결의 비용 최소화 원칙의 결과입니다. 모호함을 피하려면 함수를 오버로드할 때 암시적 변환과 오버로드 유형을 모두 고려하는 것이 중요합니다.</p></:is_convertible></typename>

위 내용은 C 오버로드 해결에서 포인터 붕괴가 추론된 템플릿보다 우선하는 이유는 무엇입니까?의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!