Создание некорректного нетемплифицированного метода шаблонного класса

Question

Я занимался поиском по two phase name lookup. Очень логичное объяснение показывает, что one of the main reasoning - это то, что следует за философией C++ ошибками лова как можно скорее.

Мой вопрос в том, почему эта философия не придерживается не-шаблонных методов. Вместо того, чтобы проверять, когда и когда вызывается метод, почему бы не проверить все не templated методы в фазе 2 при создании шаблона класса?

т.д .:

template <class T> 
struct X { 

    auto foo() // non-templated (important) 
    { 
    T t{}; 
    return t.non_existing(); 
    } 
}; 

int main() 
{ 
    X<int> x; // (1) this compiles OK. 

    // somewhere is a galaxy far far away, 
    // maybe deep inside some unrelated code 
    x.foo(); // (2) the error is here 
} 

Если вы никогда не писать (2) программа компилируется и работает без каких-либо проблем, хотя foo является незаконным для реализованного X<int>.

Я думаю, что строка (1) должна генерировать ошибку, независимо от того, когда вы когда-либо звоните foo или нет.

При написании шаблонных классов это может пропустить пролом трещины, пока вы, наконец, не назовете этот проблемный метод (2), вместо получения ошибки при создании шаблона (1).

Также проверка работоспособности: является ли код действительным, если я создаю экземпляр X<int> (1), но никогда не звоню X<int>::foo (2)? Или это что-то вроде «плохо сформированного, никакой диагностики не требуется»? Если последнее, то это еще больше причин, чтобы поймать ошибку раньше.

Answer 1

Код действителен.

Эта функция была разработана для того, чтобы разрешить такие вещи, как std::vector, имеющим operator< или operator==.

Этот оператор попытается позвонить в < или == по его элементам, слепо. Если он был недействителен, после того, как вы вызвали < или == на обертке vector, он не смог скомпилировать.

Но если вы этого не сделали, то vector будет работать нормально.

Современный C++ бы посоветовал использовать SFINAE методу условного метода или C++ 20 Требуется положение, поэтому vector бы только иметь с == или <, если это было законная операция. Ни один из этих методов, где созрел, когда был создан vector, и способность иметь методы классов шаблонов, где недействительна, была важной особенностью.

Наверху раннего отказа по недействительному коду, имеющему == условно существует разрешающий код для обнаружения, если == безопасен для вызова: древняя техника не позволяет эту интроспекцию. Мне пришлось писать пользовательские черты, которые специализируются на стандартных шаблонах контейнеров, чтобы определить, можно ли < безопасно звонить по крайней мере в одном случае.