std :: is_constructible은 개인 생성자에 대해 일치하지 않는 값을 반환합니다

std::is_constructible개인 생성자 를 처리 하는 규칙은 무엇입니까 ? 다음 코드가 주어진다 :

#include <iostream>

class Class {
private:
    Class() { }
};

template <typename T>
class Test {
public:
    static void test() {
        std::cout
            //<< std::is_constructible<Class>::value
            << std::is_constructible<T>::value
            << std::endl;
    }
};

int main() {
    Test<Class>::test();
}

이것은 프린트 0( ideone )입니다. 즉, T기본적으로 구성 할 수 없습니다.

주석 처리 된 행의 주석을 해제하면 11( ideone ) 이 인쇄 되므로 갑자기T 기본 구성 가능하게되었습니다.

두 결과를 모두 뒷받침하는 추론을 찾을 수는 있지만 주석 처리 된 줄을 포함 시키면 두 번째 결과가 어떻게 바뀌는 지 이해할 수 없습니다. 이것이 어떻게 든 UB를 호출합니까? 이것은 컴파일러 버그입니까? 아니면 std::is_constructible실제로 일관성이 없습니까?

std::is_constructiblefalse생성자에 액세스 할 수 없으므로이 시나리오에서 리턴해야합니다 .

질문 아래에서 지적했듯이 질문에 설명 된 동작은 GCC / libstdc ++의 버그로 인해 발생합니다. 버그는 여기 에 보고되었으며 Bugzilla에 따르면 꽤 오랫동안 해결되지 않은 템플릿 함수의 클래스에 대한 액세스 제어 버그로 인한 것이 아닌지와 관련이 있습니다. 두 버그 사이의 관계는 두 버그 사이의 연결을 먼저 감지 한 것으로 보이는 Jonathan Wakely의 Bugzilla 의견에서 가져 왔습니다.

이는 생성자를 비공개로 만드는 대신 생성자를 삭제할 때 GCC에서이 시나리오의 동작이 올바르게된다는 사실에 의해 암시됩니다.

class Class {
    Class() = delete;
};

어떤 인쇄 출력 0및 00각각. 이것은 올바른 결과입니다 ( clang개인 생성자와 함께 시나리오에서 올바르게보고합니다).

이것은 줄을 주석 처리 할 때 관찰 된 동작의 변화를 설명 할 수 있습니다 . 템플릿 구조 의 함수 내에서 액세스 검사가 작동하지 않고 생성자가 액세스 할 수없는 경우 생성자가 액세스 할 수 있다고보고하기 때문입니다. 다음 줄에서 또는 완전히 다른 위치에서 특성을 다시 확인하면 ( 여기서 와 같이) 이미 인스턴스화되어 잘못된 답을 얻습니다.