Inside the definition of a template (both class template and function template), the meaning of some constructs may differ from one instantiation to another. In particular, types and expressions may depend on types of type template parameters and values of constant template parameters.
template<typename T>
struct X : B<T> // âB<T>â is dependent on T
{
typename T::A* pa; // âT::Aâ is dependent on T
// (see below for the meaning of this use of âtypenameâ)
void f(B<T>* pb)
{
static int i = B<T>::i; // âB<T>::iâ is dependent on T
pb->j++; // âpb->jâ is dependent on T
}
};
Name lookup and binding are different for dependent names and non-dependent names.
[edit] Binding rulesNon-dependent names are looked up and bound at the point of template definition. This binding holds even if at the point of template instantiation there is a better match:
#include <iostream>
void g(double) { std::cout << "g(double)\n"; }
template<class T>
struct S
{
void f() const
{
g(1); // âgâ is a non-dependent name, bound now
}
};
void g(int) { std::cout << "g(int)\n"; }
int main()
{
g(1); // calls g(int)
S<int> s;
s.f(); // calls g(double)
}
If the meaning of a non-dependent name changes between the definition context and the point of instantiation of a specialization of the template, the program is ill-formed, no diagnostic required. This is possible in the following situations:
Binding of dependent names is postponed until lookup takes place.
[edit] Lookup rulesThe lookup of a dependent name used in a template is postponed until the template arguments are known, at which time
(in other words, adding a new function declaration after template definition does not make it visible, except via ADL).
The purpose of this rule is to help guard against violations of the ODR for template instantiations:
// an external library
namespace E
{
template<typename T>
void writeObject(const T& t)
{
std::cout << "Value = " << t << '\n';
}
}
// translation unit 1:
// Programmer 1 wants to allow E::writeObject to work with vector<int>
namespace P1
{
std::ostream& operator<<(std::ostream& os, const std::vector<int>& v)
{
for (int n : v)
os << n << ' ';
return os;
}
void doSomething()
{
std::vector<int> v;
E::writeObject(v); // Error: will not find P1::operator<<
}
}
// translation unit 2:
// Programmer 2 wants to allow E::writeObject to work with vector<int>
namespace P2
{
std::ostream& operator<<(std::ostream& os, const std::vector<int>& v)
{
for (int n : v)
os << n << ':';
return os << "[]";
}
void doSomethingElse()
{
std::vector<int> v;
E::writeObject(v); // Error: will not find P2::operator<<
}
}
In the above example, if non-ADL lookup for operator<< were allowed from the instantiation context, the instantiation of E::writeObject<vector<int>> would have two different definitions: one using P1::operator<< and one using P2::operator<<. Such ODR violation may not be detected by the linker, leading to one or the other being used in both instances.
To make ADL examine a user-defined namespace, either std::vector should be replaced by a user-defined class or its element type should be a user-defined class:
namespace P1
{
// if C is a class defined in the P1 namespace
std::ostream& operator<<(std::ostream& os, const std::vector<C>& v)
{
for (C n : v)
os << n;
return os;
}
void doSomething()
{
std::vector<C> v;
E::writeObject(v); // OK: instantiates writeObject(std::vector<P1::C>)
// which finds P1::operator<< via ADL
}
}
Note: this rule makes it impractical to overload operators for standard library types:
#include <iostream>
#include <iterator>
#include <utility>
#include <vector>
// Bad idea: operator in global namespace, but its arguments are in std::
std::ostream& operator<<(std::ostream& os, std::pair<int, double> p)
{
return os << p.first << ',' << p.second;
}
int main()
{
typedef std::pair<int, double> elem_t;
std::vector<elem_t> v(10);
std::cout << v[0] << '\n'; // OK, ordinary lookup finds ::operator<<
std::copy(v.begin(), v.end(),
std::ostream_iterator<elem_t>(std::cout, " "));
// Error: both ordinary lookup from the point of definition of
// std::ostream_iterator and ADL will only consider the std namespace,
// and will find many overloads of std::operator<<, so the lookup will be done.
// Overload resolution will then fail to find operator<< for elem_t
// in the set found by the lookup.
}
Note: limited lookup (but not binding) of dependent names also takes place at template definition time, as needed to distinguish them from non-dependent names and also to determine whether they are members of the current instantiation or members of unknown specialization. The information obtained by this lookup can be used to detect errors, see below.
[edit] Dependent typesThe following types are dependent types :
decltype applied to a type-dependent expressionThe result of decltype applied to a type-dependent expression is a unique dependent type. Two such results refer to the same type only if their expressions are equivalent.
(since C++11)The pack indexing specifier applied to a type-dependent constant expression is a unique dependent type. Two such pack indexing specifiers refer to the same type only if their constant expressions are equivalent. Otherwise, two such pack indexing specifiers refer to the same type only if their indices have the same value.
(since C++26)Note: a typedef member of a current instantiation is only dependent when the type it refers to is.
[edit] Type-dependent expressionsThe following expressions are type-dependent :
__func__ (if some enclosing function is a template, a non-template member of a class template, or a generic lambda(since C++14))The following expressions are never type-dependent because the types of these expressions cannot be:
[edit] Value-dependent expressionsThe following expressions are value-dependent :
Within a class template definition (including its member functions and nested classes) some names may be deduced to refer to the current instantiation. This allows certain errors to be detected at the point of definition, rather than instantiation, and removes the requirement on the typename and template disambiguators for dependent names, see below.
Only the following names can refer to the current instantiation:
A template argument is equivalent to a template parameter if
template<class T>
class A
{
A* p1; // A is the current instantiation
A<T>* p2; // A<T> is the current instantiation
::A<T>* p4; // ::A<T> is the current instantiation
A<T*> p3; // A<T*> is not the current instantiation
class B
{
B* p1; // B is the current instantiation
A<T>::B* p2; // A<T>::B is the current instantiation
typename A<T*>::B* p3; // A<T*>::B is not the current instantiation
};
};
template<class T>
class A<T*>
{
A<T*>* p1; // A<T*> is the current instantiation
A<T>* p2; // A<T> is not the current instantiation
};
template<int I>
struct B
{
static const int my_I = I;
static const int my_I2 = I + 0;
static const int my_I3 = my_I;
static const long my_I4 = I;
static const int my_I5 = (I);
B<my_I>* b1; // B<my_I> is the current instantiation:
// my_I has the same type as I,
// and it is initialized with only I
B<my_I2>* b2; // B<my_I2> is not the current instantiation:
// I + 0 is not a single identifier
B<my_I3>* b3; // B<my_I3> is the current instantiation:
// my_I3 has the same type as I,
// and it is initialized with only my_I (which is equivalent to I)
B<my_I4>* b4; // B<my_I4> is not the current instantiation:
// the type of my_I4 (long) is not the same as the type of I (int)
B<my_I5>* b5; // B<my_I5> is not the current instantiation:
// (I) is not a single identifier
};
Note that a base class can be the current instantiation if a nested class derives from its enclosing class template. Base classes that are dependent types but are not the current instantiation are dependent base classes:
template<class T>
struct A
{
typedef int M;
struct B
{
typedef void M;
struct C;
};
};
template<class T>
struct A<T>::B::C : A<T>
{
M m; // OK, A<T>::M
};
A name is classified as a member of the current instantiation if it is
::) names the current instantiation and lookup finds the name in the current instantiation or in its non-dependent basetemplate<class T>
class A
{
static const int i = 5;
int n1[i]; // i refers to a member of the current instantiation
int n2[A::i]; // A::i refers to a member of the current instantiation
int n3[A<T>::i]; // A<T>::i refers to a member of the current instantiation
int f();
};
template<class T>
int A<T>::f()
{
return i; // i refers to a member of the current instantiation
}
Members of the current instantiation may be both dependent and non-dependent.
If the lookup of a member of current instantiation gives a different result between the point of instantiation and the point of definition, the lookup is ambiguous. Note however that when a member name is used, it is not automatically converted to a class member access expression, only explicit member access expressions indicate members of current instantiation:
struct A { int m; };
struct B { int m; };
template<typename T>
struct C : A, T
{
int f() { return this->m; } // finds A::m in the template definition context
int g() { return m; } // finds A::m in the template definition context
};
template int C<B>::f(); // error: finds both A::m and B::m
template int C<B>::g(); // OK: transformation to class member access syntax
// does not occur in the template definition context[edit] Unknown specializations
Within a template definition, certain names are deduced to belong to an unknown specialization, in particular,
:: is a dependent type that is not a member of the current instantiationtemplate<typename T>
struct Base {};
template<typename T>
struct Derived : Base<T>
{
void f()
{
// Derived<T> refers to current instantiation
// there is no âunknown_typeâ in the current instantiation
// but there is a dependent base (Base<T>)
// Therefore, âunknown_typeâ is a member of unknown specialization
typename Derived<T>::unknown_type z;
}
};
template<>
struct Base<int> // this specialization provides it
{
typedef int unknown_type;
};
This classification allows the following errors to be detected at the point of template definition (rather than instantiation):
template<class T>
class A
{
typedef int type;
void f()
{
A<T>::type i; // OK: âtypeâ is a member of the current instantiation
typename A<T>::other j; // Error:
// âotherâ is not a member of the current instantiation
// and it is not a member of an unknown specialization
// because A<T> (which names the current instantiation),
// has no dependent bases for âotherâ to hide in.
}
};
Members of unknown specialization are always dependent, and are looked up and bound at the point of instantiation as all dependent names (see above)
[edit] The typename disambiguator for dependent namesIn a declaration or a definition of a template, including alias template, a name that is not a member of the current instantiation and is dependent on a template parameter is not considered to be a type unless the keyword typename is used or unless it was already established as a type name, e.g. with a typedef declaration or by being used to name a base class.
#include <iostream>
#include <vector>
int p = 1;
template<typename T>
void foo(const std::vector<T> &v)
{
// std::vector<T>::const_iterator is a dependent name,
typename std::vector<T>::const_iterator it = v.begin();
// without âtypenameâ, the following is parsed as multiplication
// of the type-dependent data member âconst_iteratorâ
// and some variable âpâ. Since there is a global âpâ visible
// at this point, this template definition compiles.
std::vector<T>::const_iterator* p;
typedef typename std::vector<T>::const_iterator iter_t;
iter_t * p2; // âiter_tâ is a dependent name, but it is known to be a type name
}
template<typename T>
struct S
{
typedef int value_t; // member of current instantiation
void f()
{
S<T>::value_t n{}; // S<T> is dependent, but âtypenameâ not needed
std::cout << n << '\n';
}
};
int main()
{
std::vector<int> v;
foo(v); // template instantiation fails: there is no member variable
// called âconst_iteratorâ in the type std::vector<int>
S<int>().f();
}
The keyword typename may only be used in this way before qualified names (e.g. T::x), but the names need not be dependent.
Usual qualified name lookup is used for the identifier prefixed by typename. Unlike the case with elaborated type specifier, the lookup rules do not change despite the qualifier:
struct A // A has a nested variable X and a nested type struct X
{
struct X {};
int X;
};
struct B
{
struct X {}; // B has a nested type struct X
};
template<class T>
void f(T t)
{
typename T::X x;
}
void foo()
{
A a;
B b;
f(b); // OK: instantiates f<B>, T::X refers to B::X
f(a); // error: cannot instantiate f<A>:
// because qualified name lookup for A::X finds the data member
}
The keyword typename can be used even outside of templates.
#include <vector>
int main()
{
// Both OK (after resolving CWG 382)
typedef typename std::vector<int>::const_iterator iter_t;
typename std::vector<int> v;
}
In some contexts, only type names can validly appear. In these contexts, a dependent qualified name is assumed to name a type and no typename is required:
static_cast, dynamic_cast, const_cast, or reinterpret_cast.Similarly, in a template definition, a dependent name that is not a member of the current instantiation is not considered to be a template name unless the disambiguation keyword template is used or unless it was already established as a template name:
template<typename T>
struct S
{
template<typename U>
void foo() {}
};
template<typename T>
void bar()
{
S<T> s;
s.foo<T>(); // error: < parsed as less than operator
s.template foo<T>(); // OK
}
The keyword template may only be used in this way after operators :: (scope resolution), -> (member access through pointer), and . (member access), the following are all valid examples:
As is the case with typename, the template prefix is allowed even if the name is not dependent or the use does not appear in the scope of a template.
Even if the name to the left of :: refers to a namespace, the template disambiguator is allowed:
template<typename>
struct S {};
::template S<void> q; // allowed, but unnecessary
Due to the special rules for unqualified name lookup for template names in member access expressions, when a non-dependent template name appears in a member access expression (after -> or after .), the disambiguator is unnecessary if there is a class or alias(since C++11) template with the same name found by ordinary lookup in the context of the expression. However, if the template found by lookup in the context of the expression differs from the one found in the context of the class, the program is ill-formed(until C++11)
template<int>
struct A { int value; };
template<class T>
void f(T t)
{
t.A<0>::value; // Ordinary lookup of A finds a class template.
// A<0>::value names member of class A<0>
// t.A < 0; // Error: â<â is treated as the start of template argument list
}(until C++23) [edit] Keywords
[edit] Defect reports
The following behavior-changing defect reports were applied retroactively to previously published C++ standards.
DR Applied to Behavior as published Correct behavior CWG 206 C++98 it was unspecified at what point semantic constraints are:: where the name to its left refers to a namespace allowed CWG 2066 C++98 this was never value-dependent it may be
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4