The Problem

Вот краткая демонстрация проблемы с MSVC 6.x:

template< typename F, typename T > struct apply1
{
    typedef typename F::template apply<T>::type type;
};

Пытаясь составить этот невинно выглядящий код, мы получаем:

portability.cpp(4) : error C2903: 'apply' : symbol is neither a class template 
            nor a function template
        portability.cpp(5) : see reference to class template instantiation 
            'apply1<F,T>' being compiled
portability.cpp(4) : error C2143: syntax error : missing ',' before '<'
        portability.cpp(5) : see reference to class template instantiation 
            'apply1<F,T>' being compiled
portability.cpp(4) : error C2059: syntax error : '<'
        portability.cpp(5) : see reference to class template instantiation 
            'apply1<F,T>' being compiled

Символ не является ни шаблоном класса, ни шаблоном функции; часть диагностики на самом деле часто указывает на проблемы, связанные с ИППП. Другое типичное сообщение об ошибке обычно говорит о том, что вложенный тип не является членом глобального пространства имен.

Оба случая являются двумя сторонами одной и той же ошибки компилятора, которую мы называем "раннее создание шаблона": компилятор для внутренних целей, для обработки определений шаблонов классов, инстанцирует шаблоны классов с фиктивными параметрами шаблона (int). Это может произойти как во время разбора определений шаблонов (и такие ошибки легче всего идентифицировать и исправить — само определение шаблона просто не компилируется; пример выше попадает в эту категорию), так и позже во время инстанциации шаблона, и это трудно обнаружить — ошибка будет запущена только в определенном контексте.

ETI всегда выполняется во время разбора определения шаблона пространства имен, что в основном означает, что любое определение шаблона, которое становится недействительным, заменяя его параметры шаблона ints, может не компилироваться, как это произошло с нашим примером:

template< typename F, typename T > struct apply1
{
    // typedef typename F::template apply<T>::type type;
    // ETI generates this: 
    typedef typename int::template apply<int>::type type;
};

Если вы сделаете это, вы получите точно Диагностика, которую мы только что видели.

Обратите внимание, что мы сказали "может не компилировать", потому что ... ну, короткий ответ: "это зависит". Мы не анализировали вещи до такой степени, что мы могли бы сказать вам точное состояние, когда ETI приводит к ошибке, а когда нет, но это не очень важно в любом случае - если это ошибка, вы просто исправите ее (мы покажем вам, как через секунду), и если это не так, то вы оставляете вещи такими, какие они есть. Если однажды потенциальная проблема превратится в реальную, вы применяете обходной путь, который мы собираемся вам дать.

The Symptoms

Мы уже рассмотрели типичную диагностику, поэтому не будем повторяться. Вместо этого мы просто упомянем, что многие внутренние ошибки MSVC на самом деле вызваны проблемой, связанной с ETI, где-то в глубине стека инстанциации.

The Solution

В этом случае мы не можем изменить поведение компилятора, поэтому нам нужно приспособиться к нему и заставить наши шаблоны делать то, что мы хотим. Удивительно, но в большинстве случаев добиться этого довольно просто:

// potentially unsafe
template< typename F > struct apply0
{
    typedef typename F::type type;
};
// now ETI-safe
template<> struct apply0<int>
{
    typedef int type;
};

Поскольку исходный шаблон никогда не мог быть инстанцирован с int, предоставление специализации stub int совершенно невинно.