문제

(전문: 나는 C ++ 0X 게임에 늦은 추종자이며 C ++ 0X 표준에서 개념을 제거하는 것에 관한 최근의 논쟁은 그들에 대해 더 많이 배우도록 동기를 부여했습니다. 내 모든 질문이 완전히 가상적이라는 것을 이해하고 있지만, 개념은 앞으로 얼마 동안 C ++ 코드가 유효하지 않은 한, 특히 개념에 대해 더 많이 배우는 데 관심이 있습니다. 나는 최근의 결정과 뒤 따른 논쟁의 장점을 더 잘 이해합니다)

C ++ 0X (최근까지)가 제안한 것처럼 개념에 대한 소개 자료를 읽은 후, 나는 일부 구문 문제에 대해 내 마음을 감싸는 데 어려움을 겪고 있습니다. 더 이상 고민하지 않고 여기에 내 질문이 있습니다.

1) 특정 파생 개념을 지원하는 유형 (자동 키워드를 통해 또는 Concept_maps를 통해 명시 적으로)도 기본 개념을 미숙하게 지원해야합니까? 다시 말해, 다른 사람에게서 개념을 도출하는 행위는 (예 : concept B<typename T> : A<T>) 암시 적으로 'Invisible'요구 사항을 포함합니다 (b, 내에서 requires A<T>;)? 혼란은 위키 백과 페이지에서 다음과 같은 개념에 관한 것입니다.

클래스 상속과 마찬가지로, 파생 된 개념의 요구 사항을 충족하는 유형도 기본 개념의 요구 사항을 충족합니다.

그것은 유형이 파생 된 개념의 요구 사항을 만족시키기 만하면되며 반드시 기본 개념의 요구 사항은 아니라고 말하는 것 같습니다. 나는 Wikipedia가 결정적인 출처와는 거리가 멀다는 것을 이해합니다. 위의 설명은 단지 불량한 단어 선택일까요?

2) 타이프 이름을 나열하는 개념이 '자동'일 수 있습니까? 그렇다면 컴파일러는 어떻게이 타이프 이름을 자동으로 맵핑합니까? 그렇지 않다면 개념에서 '자동'을 사용하는 것이 유효하지 않은 다른 경우가 있습니까?

명확히하려면 다음 가상 코드를 고려하십시오.

template<typename Type>
class Dummy {};

class Dummy2 { public: typedef int Type; };

auto concept SomeType<typename T>
{
     typename Type;
}

template<typename T> requires SomeType<T>
void function(T t)
{}

int main()
{
    function(Dummy<int>()); //would this match SomeType?
    function(Dummy2()); //how about this?
    return 0;
}

해당 클래스 중 하나가 Somwentype과 일치합니까? 아니면 타이프 이름과 관련된 개념에 Concept_map이 필요합니까?

3) 마지막으로, 나는 공리를 정의 할 수있는 것을 이해하는 데 어려움을 겪고 있습니다. 예를 들어, 개념이 논리적으로 일치하지 않는 공리를 정의 할 수 있습니까?

concept SomeConcept<typename T>
{
    T operator*(T&, int);

    axiom Inconsistency(T a)
    {
         a * 1 == a * 2;
    }
} 

그게 어떻게 될까요? 그게 유효합니까?

나는 이것이 매우 긴 질문이라는 것을 고맙게 생각합니다. 그래서 미리 감사드립니다.

도움이 되었습니까?

해결책

가장 최근의 C ++ 0X 드래프트를 사용했습니다. N2914 다음 답변에 대한 참조로서 (여전히 개념 문구가 있습니다).

1) 개념은 그 인터페이스와 같습니다. 유형이 개념을 지원하는 경우 모든 "기본"개념도 지원해야합니다. Wikipedia 문장 당신이 인용 한 유형의 클라이언트의 관점에서 의미가 있습니다. T 개념을 만족시킵니다 Derived<T>, 그리고 그는 또한 그것이 개념을 만족 시킨다는 것을 알고 있습니다 Base<T>. 유형의 저자 관점에서 이것은 자연스럽게 둘 다 구현되어야 함을 의미합니다. 14.10.3/2를 참조하십시오.

2) 예, 개념 typename 회원이 될 수 있습니다 auto. 이러한 멤버는 동일한 개념의 기능 구성원의 정의에 사용되면 자동으로 추론 할 수 있습니다. 예를 들어, value_type 반복자의 경우 반환 유형으로 추론 할 수 있습니다. operator*. 그러나 유형 멤버가 어느 곳에서나 사용되지 않으면 추론되지 않으므로 암시 적으로 정의되지 않습니다. 당신의 예에서는 추론 할 방법이 없습니다 SomeType<T>::Type 어느 쪽이든 Dummy 또는 Dummy1, 처럼 Type 이 개념의 다른 멤버는 사용하지 않으므로 클래스는 개념에 매핑되지 않습니다 (실제로 클래스는 자동 매핑 할 수 없습니다). 14.10.1.2/11 및 14.10.2.2/4를 참조하십시오.

3) 공리는 사양의 약점이었으며, 일부 (더 많은) 의미를 갖도록 지속적으로 업데이트되었습니다. 초안에서 개념을 가져 오기 직전에 종이 그것은 상당히 바뀌 었습니다 - 그것을 읽고 그것이 당신에게 더 합리적인지 또는 여전히 그것에 관한 질문이 있는지 확인하십시오.

특정 예제 (구문 차이를 설명)의 경우, 컴파일러가 표현을 고려할 수 있음을 의미합니다. (a*1) 동일합니다 (a*2), 언어의 "as-if"규칙의 목적 상 (즉, 결과가 동작하는 한 원하는 최적화를 할 수 있도록 허용되었습니다. 마치 아무것도 없었다). 그러나 컴파일러는 공리의 정확성을 검증하는 데 필요한 방식으로는 필요하지 않습니다 (따라서 공리라고 불리는 이유) - 단지 그들이 무엇인지에 대해 가져갑니다.

라이센스 : CC-BY-SA ~와 함께 속성
제휴하지 않습니다 StackOverflow
scroll top