我必须在何处以及为什么要放置“模板”。和“ typename”关键字？

Question

在模板中，在何处以及为什么必须将typename和模板放在依赖名称上？
无论如何，依赖名称到底是什么？

我有以下代码：

template <typename T, typename Tail> // Tail will be a UnionNode too.
struct UnionNode : public Tail {
    // ...
    template<typename U> struct inUnion {
        // Q: where to add typename/template here?
        typedef Tail::inUnion<U> dummy; 
    };
    template< > struct inUnion<T> { };
};
template <typename T> // For the last node Tn.
struct UnionNode<T, void> {
    // ...
    template<typename U> struct inUnion; // intentionally not defined
    template< > struct inUnion<T> { };   // specialization only for T
};

我遇到的问题在于typedef tail :: Inunion＆lt; u＆gt;虚拟行。我可以肯定的是，innunion是一个因名称，而VC ++在cho住了它的位置很合适。

我还知道我应该能够在某个地方添加template告诉编译器Inunion是 template-id ，但是到底在哪里？然后，应该假设innuion是类模板，即innunion＆lt; u＆gt; name name name and andes not type而不是函数？

Answer 1

C ++ 20和C ++ 23

对于感兴趣的人，我将从现代C ++的角度提供完整的答案。
C ++ 20和C ++ 23之间只有很小的差异。

为什么我们需要模板和typename？

基本问题是，没有其他提示，编译器无法理解C ++。正式地，C ++语法是上下文敏感的，您需要提供其他disamuguators。

int x, y;

template <typename T>
void f() {
    T::type * x;
    // if 'type' is a type, then this is declaring 'x' as a pointer to 'T::type'
    // if 'type' is a static data member, this is multiplying 'x' with 'T::type'
    typename T::type* x; // unambiguous

    T::templ<0>> y;
    // if 'templ' is a template, then this is ( (T::templ<0>) > y) )
    // if 'templ' is a static data member, this is ((T::templ < 0) >> y)
    T::template templ<0>> y; // unambiguous
}

如您所见，问题是t可以是任何类型，因此t ::类型和t :: Templ可以是任何东西：静态数据成员，类型别名，模板，成员函数模板，非模板成员函数等。
这是因为t :: Type和t :: Templ是相关类型，取决于模板参数t。

C ++通过将t ::某物作为数据成员或成员函数来解决这种歧义。您指定template或typename是被解释为类型或模板的东西。

依赖类型和表达式

概括术语的

• ： t :: Type之类的类型是依赖性模板参数t。
• （x+y）之类的表达 - 依赖性如果x或y依赖于模板类型参数。
• （x+y）之类的表达 - 依赖性如果x或y依赖于非类型模板参数。

通常，当涉及依赖类型时，typename template 是必要的。如果从依赖的表达式形成依赖类型，例如decltype（x + y）::类型也可能发生这种情况。

模板和typename关键字如何工作？

这些关键字有时被称为Disamamutorator，并告知编译器您需要类型或模板而不是数据成员/成员函数。

typename disambuator

typename被准备到 typename特定词，并适用于需要歧义的名字。例如：

typename T::type // interpreted as type
   │        ▲
   └────────┘

typename T::type::type // interpreted as type
   │              ▲
   └──────────────┘

typename T::templ<0>::type // interpreted as non-type
   │        ▲
   └────────┘

typename T::template templ<0>::type // interpreted as a type
   │                           ▲
   └───────────────────────────┘

template disambiguator

template在合格 - id ，使其如此＆lt;不是被解释为不太少的操作员，而是一个开始 template-argument-list 。

T::templ<0> // '<' is interpreted as less-than

T::template templ<0> // '<0>' is interpreted as template-argument-list

T::template templ<0>::templ<1> // '<1' is interpreted as less than 1

typename T::templ<0> // '<0>' is interpreted as template-argument-list
   │        ▲        // due to type-only context
   └────────┘

如上一个示例所示，typename可以使模板不必要，因为templ＆lt;只能将其解释为a template-argument-list 如果templ必须是一种类型。

模板有另一种（现在已弃用）的使用，即提供template-template参数：

template <template <typename> typename TT>
void f();

template <typename T>
void g() { f<T::template templ>(); }

此用途已被弃用，因为始终很明显＆lt; ...＆gt;是a template-argument-list 在此上下文中和模板是毫无意义的。

C ++ 20和C ++ 23放松是多少？

模板和typename的许多用途现已变得不必要。如上所述，typename有时制作模板不必要。更一般地，typename和模板可以省略仅类型的上下文。

例如：

using T = T::type;         // OK
static_cast<T::type>(...); // OK
std::is_const_v<T::type>;  // OK
void f(T::type t);         // OK

这些用途和其他用途将在C ++ 20之前被不良形成。 C ++ 23添加了template和typename之间的交互，这消除了进一步的用途。
相关建议是：

• typename ！（C ++ 20）
• p1787：声明和在哪里可以找到它们（C ++ 23）

，通常会努力消除typename and code>和模板的所有位置并不是真正必要的。
请注意，template和typename并不总是需要歧义，而只是有助于解析。例如：

typename T::a::b::c::d::e::f::g::h::i::j x,

在这里，我们仍然需要typename，尽管明确是声明。否则，知道a是一种类型和a ::是有效的。

因此，在这种情况下，typename不太可能成为可选的。

Answer 2

依赖名称是名称取决于模板参数，我们需要指示编译器以正确编译模板类/功能，然后才能实际进行分组。

• 打字机 - ＆gt;告诉编译器依赖性名称是实际类型

   模板＆lt;类T＆gt;
  构造依赖性
  {
    TypeName t :: type a;
    使用type = typeName t ::类型;
  };
  
   

• 模板 - ＆gt;告诉编译器依赖名称是模板函数/class

   模板＆lt;类T＆gt;
  结构依赖性板
  {
    //模板功能
    模板＆lt; class u＆gt;
    静态void func（）{}
  
    //模板类
    模板＆lt; class u＆gt;
    struct className {};
  };
  
  
  模板＆lt;类T1类，T2＆gt;
  void foo（）
  {
    //调用依赖模板功能的3种方法
    rentionentTemplate＆lt; t1＆gt; :: template func＆lt; t2＆gt;（）;
    depententTemplate＆lt; t1＆gt;（）。模板func＆lt; t2＆gt;（）;
    （new依赖性板块＆lt; t1＆gt;（）） - ＆gt; template func＆lt; t2＆gt;（）;
  
    //您需要类型和模板来引用因模板类
    typeName依赖性板＆lt; t1＆gt; :: template className＆lt; t2＆gt; t2＆gt; obj;
    使用type = typeName依赖性图板＆lt; t1＆gt; :: template className＆lt; t2＆gt;;;
  }
   

Answer 3

我放置Jlborges的出色 wornge ，因为这是我阅读的有关该主题的最简洁的解释。

在我们编写的模板中，有两种可以使用的名称 - 相关名称和非依赖性名称。依赖名称是取决于模板参数的名称；非依赖性名称具有相同的含义，无论模板参数是什么。

例如：

 模板＆lt; T＆gt; typename void foo（t＆amp; x，std :: string str，int count）
{
    //这些名称在第二阶段查找
    //当实例化FOO并已知T型时
    X.Size（）; //依赖名称（非类型）
    t :: instance_count; //依赖名称（非类型）
    typename t :: iterator i; //依赖名称（类型）
      
    //在第一阶段， 
    // t :: instance_count被视为非类型（这是默认值）
    // TypEname关键字指定t :: iterator被视为一种类型。

    //这些名称在第一阶段查找
    std :: string :: size_type s; //非依赖性名称（类型）
    std :: string :: npos; //非依赖性名称（非类型）
    str.empty（）; //非依赖性名称（非类型）
    数数 ; //非依赖性名称（非类型）
}
 

对于模板的每个不同实例化而言，依赖名称所指的内容可能是不同的。结果，C ++模板受“两相名称查找”的约束。当最初解析模板（在发生任何实例化之前）时，编译器查找非依赖性名称。当发生模板的特定实例化时，模板参数会在当时知道，并且编译器查找相关名称。

在第一阶段，解析器需要知道因名称是类型的名称还是非类型的名称。默认情况下，假定依赖的名称为非类型的名称。依赖名称之前的打字名称关键字指定它是类型的名称。

---

摘要

仅在模板声明和定义中使用关键字TypeName，前提是您具有指称类型的合格名称，并取决于模板参数。

Answer 4

Simple

You need it when you call a templated function from inside a templated class:

LiveDemo

#include <iostream>
#include <string>

struct printable {
    std::string mystr = "Hello World";
    template <typename T>
    auto print() {
        if constexpr (std::same_as<T, std::string>) {
            std::cout << mystr << std::endl;
        }
    }
};


template <typename Printable>
struct entity {
    auto print(Printable& myprintable) {
        myprintable.template print<std::string>();
    }
};

int main() {

    entity<printable> e;
    printable p;

    e.print(p);
}

Will output

Hello World

from the templated print() function在可打印中。

Answer 5

（请参阅在这里也为我的C ++ 11答案）

为了解析C ++程序，编译器是否需要知道是否需要知道某些名称是否类型。以下示例表明：

t * f;

如何解析这一点？对于许多语言，编译器不需要知道名称的含义即可解析并基本上知道代码行执行的操作。在C ++中，以上可以根据t的含义产生截然不同的解释。如果是一种类型，则将是指针f的声明。但是，如果不是类型，那将是乘法。因此，C ++标准在段（3/7）上说：

一些名称表示类型或模板。通常，每当遇到一个名称时，都必须在继续解析包含该程序的程序之前确定该名称是否表示这些实体之一。确定这称为名称查找的过程。

编译器将如何找出名称t :: x是指，如果t是指模板类型参数？ X可能是一个静态的INT数据成员，可以乘以或同样可以是嵌套类或类型的静态数据成员，可以屈服于声明。 如果一个名称具有此属性 - 直到已知实际的模板参数才能查找 - 则称为a 依赖性名称（“取决于”模板参数）。

您可能建议您只等到用户实例化模板：

让我们等到用户实例化模板，然后稍后找出t :: x * f;。

的真实含义。

，这将起作用，并实际上由标准允许作为可能的实施方法。这些编译器基本上将模板的文本复制到内部缓冲区中，并且只有在需要实例化时，它们才会解析模板并可能检测到定义中的错误。但是，其他实施方式并没有用模板作者的错误来打扰模板的用户（可怜的同事！），而是选择尽早检查模板并在实例化发生之前尽快在定义中检查模板。

因此，必须有一种方法告诉编译器某些名称是类型，而某些名称则不是。

“打字”关键字

答案是：我们决定编译器应如何解析此内容。如果t :: x是一个因名称，则我们需要通过typename前缀它来告诉编译器以某种方式解析它。该标准在（14.6/2）上说：

模板声明或定义中使用的名称，取决于模板参数是
假定不命名类型，除非适用的名称查找找到类型名称或名称是合格的
由关键字TypeName。

有很多名称typename不需要，因为编译器可以在模板定义中使用适用的名称查找，找出如何解析构造本身 - 例如使用t * f;，当t是类型模板参数时。但是，对于t :: x * f;要成为声明，必须将其写入typename t :: x * f;。如果您省略了关键字，并且名称被视为非类型，但是当实例化发现它表示类型时，则编译器会发出通常的错误消息。有时，在定义时给出错误：

// t::x is taken as non-type, but as an expression the following misses an
// operator between the two names or a semicolon separating them.
t::x f;

语法允许typeName仅在合格名称之前，因此被认为是批准的，始终知道无限制的名称是参考类型如果他们这样做。

正如介绍性文本所暗示的那样，对于表示模板的名称也存在类似的陷阱。

“模板”关键字

还记得上面的初始引用以及标准如何也需要对模板进行特殊处理？让我们以以下无辜的外观例子：

boost::function< int() > f;

对于人类读者来说，这看起来可能很明显。编译器并非如此。想象一下，boost :: function和f的以下任意定义

namespace boost { int function = 0; }
int main() { 
  int f = 0;
  boost::function< int() > f; 
}

实际上是有效的 expression ！它使用较小的操作员比较boost :: function与零（int（））进行比较，然后使用大于运算符比较结果bool针对f。但是，如您所知，boost :: function 在现实生活中是一个模板，因此编译器知道（14.2/3）：

名称查找（3.4）之后发现名称是模板名称，如果此名称后面是a＆lt; the＆lt;是
总是被视为模板 - 题词列表的开始
操作员。

现在，我们又回到了与typename的问题相同的问题。如果我们还不知道该名称是解析代码时的模板怎么办？我们需要在模板名称之前立即插入模板，如14.2/4所指定。这看起来像：

t::template f<int>(); // call a function template

模板名称不仅可以在::之后发生，还可以在类成员访问中的- ＆gt;或。。。您还需要在此处插入关键字：

this->template f<int>(); // call a function template

---

依赖项

对于架子上有厚标准书籍并且想知道我到底在说什么的人们的

，我将谈论标准中如何指定这一点。在模板声明中，一些构造的含义不同，具体取决于您用于实例化模板的模板参数：表达式可能具有不同的类型或值，变量可能具有不同的类型或函数调用可能最终会调用不同的函数。这种构造通常被认为依赖对模板参数。

该标准通过构造是否取决于规则来精确定义规则。它将它们分为逻辑上不同的群体：一种捕获类型，另一种捕获表达式。表达可能取决于其价值和/或其类型。因此，我们有典型的示例附加：

• 相关类型（例如：类型模板参数t）
• 值依赖性表达式（例如：非类型模板参数参数n）
• 类型- 依赖性表达式（例如：铸造到类型模板参数（t）0）

大多数规则都是直观的，并且是递归构建的：例如，一种构造为t [n的类型]是一种因类型，如果n是值依赖的表达式或t是一个因类型。可以在（14.6.2/1）部分中读取此详细信息，（14.6.2.2）类型依赖性表达式和（14.6） .2.3）用于值依赖的表达式。

依赖名称

标准对的确切是依赖的名称。在简单的读取中（您知道，最小令人惊讶的原理），它将其定义为依赖性名称是下面函数名称的特殊情况。但是由于清楚地t :: x还需要在实例化环境中查找，因此它也需要是一个依赖的名称（幸运的是，从C ++ 14开始，委员会已经开始研究如何修复这个令人困惑的定义）。

为了避免此问题，我诉诸于对标准文本的简单解释。在表示因类型或表达式的所有构造中，它们的一个子集表示名称。因此，这些名称是“依赖的名称”。名称可以采用不同的形式 - 标准说：

名称是使用标识符（2.11），操作员 - 函数-ID（13.5），转换 - 函数-ID（12.3.2）或Template-ID（14.2）表示实体或标签（6.6） .4，6.1）

标识符只是字符/数字的普通序列，而接下来的两个是operator +和操作员类型表单。最后一个形式是template-name＆lt;参数列表＆gt;。所有这些都是名称，并且通过标准中的常规用途，名称还可以包含预选符，以说出应该查找哪个名称空间或类名称。

值依赖于值的表达式1 + n不是名称，但n是。名称的所有相关构造的子集称为依赖性名称。但是，功能名称在模板的不同实例中可能具有不同的含义，但不幸的是，该一般规则并未捕获。

依赖函数名称

不是本文的关注点，而是值得一提的：函数名称是单独处理的例外。标识符函数名称本身不是依赖性，而是呼叫中使用的类型依赖参数表达式。在示例中f（（t）0），f是一个因名称。在标准中，这是在（14.6.2/1）中指定的。

注释和示例

在足够的情况下，我们需要typename和模板的其他 。您的代码应该看起来像以下

template <typename T, typename Tail>
struct UnionNode : public Tail {
    // ...
    template<typename U> struct inUnion {
        typedef typename Tail::template inUnion<U> dummy;
    };
    // ...
};

键Template不一定总是出现在名称的最后一部分中。它可以在中间出现在用作范围的类名称之前，例如在以下示例

typename t::template iterator<int>::value_type v;

中，禁止关键字是禁止的，如

• 依赖基类的名称所述，您不允许您写入

  typename。假定给出的名称是类类型名称。这对于基类列表和构造函数初始器列表中的两个名称都是如此：

   模板＆lt; typename t＆gt;
   struct derive_from_has_type： / * typename * / somebase＆lt; t＆gt; ::类型 
   {};
   

• 在使用declarations中， 这是正确的。 ，和C ++委员会在解决方案上。

   模板＆lt; typename t＆gt;
   struct derive_from_has_type：somebase＆lt; t＆gt; {
      使用某个base＆lt; t＆gt; ::模板类型; // 错误
      使用typeName somebase＆lt; t＆gt; :: type; // typeName *允许 *
   };
   

Answer 6

C ++ 11

问题

当C ++ 03中的规则关于您何时需要typename和Template在很大程度上是合理的，它的公式存在一个令人讨厌的劣势

template<typename T>
struct A {
  typedef int result_type;

  void f() {
    // error, "this" is dependent, "template" keyword needed
    this->g<float>();

    // OK
    g<float>();

    // error, "A<T>" is dependent, "typename" keyword needed
    A<T>::result_type n1;

    // OK
    result_type n2; 
  }

  template<typename U>
  void g();
};

。 ，即使编译器可以完美地确定a :: result_type只能是int（因此，因此是类型），并且> this-＆gt; g只能是成员模板g以后声明（即使a在某个地方明确专业化，也不会影响该模板中的代码，因此它的含义不能受到以后的a的专业化的影响！）。

当前的实例化

以改善情况，在C ++ 11中，当类型引用封闭模板时，语言跟踪。要知道，该类型必须是通过使用某种形式的名称来形成的，该名称是其自己的名称（在上面，a，a＆lt; t＆gt;，<代码> :: a＆lt; t＆gt; ）。该名称引用的一种类型已知是当前的实例化。如果形成名称的类型是成员/嵌套类（然后，，a :: nestedClass and a 是两个当前的实例化）。

基于此概念，该语言说CurrentAstantiation :: Foo，foo和currentInstantiationTypy-＆gt; foo（例如a * a = this; a-＆gt; foo）都是当前实例的成员或它的非依赖性基类之一（通过立即进行名称查找）。

关键字typename和模板现在不再需要预选赛，而预选赛是当前实例的成员。要记住的关键点是，a＆lt; t＆gt; is stall 一个依赖类型的名称（毕竟t也是键入的）。但是a＆lt; t＆gt; :: result_type是一种类型 - 编译器将“神奇地”查看这种依赖类型以弄清楚这一点。

struct B {
  typedef int result_type;
};

template<typename T>
struct C { }; // could be specialized!

template<typename T>
struct D : B, C<T> {
  void f() {
    // OK, member of current instantiation!
    // A::result_type is not dependent: int
    D::result_type r1;

    // error, not a member of the current instantiation
    D::questionable_type r2;

    // OK for now - relying on C<T> to provide it
    // But not a member of the current instantiation
    typename D::questionable_type r3;        
  }
};

这是令人印象深刻的，但是我们可以做得更好吗？该语言甚至更进一步，并且需要 再次实现d :: result_type实例化d :: f :: f（即使它找到了它的在定义时已经意思）。现在查找结果有所不同或结果歧义，该程序的形式不佳，必须给出诊断。想象一下，如果我们定义c这样会发生什么，则

template<>
struct C<int> {
  typedef bool result_type;
  typedef int questionable_type;
};

需要编译器在实例化d＆lt; int＆gt; :: f时捕获错误。因此，您可以获得两个世界中最好的：如果您在依赖基础类方面遇到麻烦，则“延迟”查找，以及“立即”查找，使您从typename和模板中释放您。。

在d的代码中未知的专业

，名称typename d :: Questable_type不是当前实例化的成员。相反，语言将其标记为未知专业化的成员。特别是，当您执行依赖性tyentTypename :: foo或dependenttypedname-＆gt; foo 时，依赖类型不是 当前的实例化（在这种情况下，编译器可以放弃，并说“稍后我们将查看foo是什么），或者IT 是 当前的实例化且名称在IT或其非依赖性基类，也有依赖性基

类

void h() {
  typename A<T>::questionable_type x;
}

。 +03，该语言允许捕获此错误，因为永远无法有一种有效的方法来实例化a＆lt; t＆gt; :: h（无论您给出> t）。在C ++ 11中，该语言现在有进一步的检查，以提供更多编译器实现此规则的原因。成员Questable_type，名称a＆lt; t＆gt; :: Questable_type nese nese nes 都不是当前实例化的成员 and> a未知专业的成员。在这种情况下，该代码在实例化时不应有效编译，因此该语言禁止名称，其中资格符是当前的实例化既不是未知专业化的成员，也不是当前实例化的成员（但是，仍然不需要诊断出这种违规行为）。

示例和琐事

您可以在

C ++ 11规则使以下有效的C ++ 03代码不正确（C ++委员会未打算，但可能无法修复）

struct B { void f(); };
struct A : virtual B { void f(); };

template<typename T>
struct C : virtual B, T {
  void g() { this->f(); }
};

int main() { 
  C<A> c; c.g(); 
}

此有效的C ++ 03代码将绑定this＆gt ; f to a :: f在实例化时，一切都很好。 C ++ 11但是，将其绑定到b :: f，并在实例化时需要进行双重检查，检查查找是否仍然匹配。但是，当实例化c＆lt; a＆gt; :: g时，优势规则应用和查找将找到a :: f而不是。

Answer 7

序言
这篇文章是易于阅读的 litb的帖子。 。 基本目的是相同的；对“何时？”的解释和“为什么？” 必须应用和 template 。

typename和模板的目的是什么？

typename和模板在声明模板以外的其他情况下是可用的。

在 c ++ 中有某些上下文，必须明确地告诉编译器如何处理名称，并且所有这些上下文都有一个共同点；它们取决于至少一个模板参数。

我们指的是解释中可能存在歧义的名称，为； “ 相关名称”。

这篇文章将为依赖名称和两个关键字之间的关系提供解释。

---

摘要说超过1000个单词

试图解释以下 function-template 对自己，朋友或您的猫的情况；标记（ a ）的语句中发生了什么？

template<class T> void f_tmpl () { T::foo * x; /* <-- (A) */ }

它可能并不像人们想象的那样容易，更具体地说是评估（ a ）的结果，重大 作为模板参数的定义 。

不同的t可以大大更改所涉及的语义。

struct X { typedef int       foo;       }; /* (C) --> */ f_tmpl<X> ();
struct Y { static  int const foo = 123; }; /* (D) --> */ f_tmpl<Y> ();

如果我们用类型 x 实例化函数 - 板，则两个不同的方案：

• ，如（ c ），我们将声明 pointer-to int naty x ，但是;

• 如果我们使用类型 y 实例 123 的乘积乘以一些已经声明的变量 x 。

---

C ++标准的理由

至少在这种情况下关心我们的安全和福祉。

为了防止实施潜在的令人讨厌的惊喜，我们通过 明确地来解决A 依赖名称的歧义的标准任务将名称视为A type-name 或A template-id 。

如果没有说明，则依赖性名称将被视为变量或函数。

---

如何处理依赖名称？

如果这是好莱坞电影，依赖性名称将是通过身体接触传播的疾病，会立即影响其宿主，使其混淆。混乱可能会导致一个形成不良的人，Erhm ..程序。

依赖性名称是直接或间接取决于A 模板参数的任何名称。

template<class T> void g_tmpl () {
   SomeTrait<T>::type                   foo; // (E), ill-formed
   SomeTrait<T>::NestedTrait<int>::type bar; // (F), ill-formed
   foo.data<int> ();                         // (G), ill-formed    
}

我们在上面的片段中有四个依赖性名称：

• e ）
  • “ type” 取决于的实例化，womentrait＆lt; t＆gt;，其中包括t和;

  


  


• f ）
  • “ nestedtrait” ，即 template-id ，取决于witherrait＆lt; t＆gt; and;
  • “ type” 在（ f ）末尾取决于 nestedtrait ，它取决于withrait＆lt; t＆gt; ，;

  


  


• g ）
  • “ data” ，看起来像成员函数模板，是间接的依赖性名称，因为的类型foo 取决于的实例化，woryrait＆lt; t＆gt;。

  


  


如果编译器会解释依赖性名称<，则语句（ e ），（ f ）或（ g ）是有效的/em>作为变量/函数（如前所述，如果我们不明确说另有说明，就会发生这种情况）。

使g_tmpl具有有效定义的解决方案

，我们必须明确地告诉编译器，我们期望在（ e ），（ f ）中的A template-id 和a type ，以及 template-id in（< em> g ）。

template<class T> void g_tmpl () {
   typename SomeTrait<T>::type foo;                            // (G), legal
   typename SomeTrait<T>::template NestedTrait<int>::type bar; // (H), legal
   foo.template data<int> ();                                  // (I), legal
}

每次a name 表示类型， all name 必须是 type-names 或 namespaces ，考虑到这一点，很容易看到我们在完全合格的名称开始时应用typename。

模板在这方面是不同的，因为没有办法得出结论，例如； “哦，这是一个模板，然后另一件事也必须是模板” 。这意味着我们直接在我们想这样对待的任何名称的前面应用模板>。

---

我可以将关键字贴在任何名称前面吗？

“ 我可以粘贴typename和模板在任何名称前？我不想担心它们出现的上下文。 。“ - 一些C ++开发人员

只要您要处理 commiquied -name -name （ k k <），标准中的规则可以应用关键字/em>），但是如果名称不是合格的，则应用程序不正确（ l ）。

namespace N {
  template<class T>
  struct X { };
}

         N::         X<int> a; // ...  legal
typename N::template X<int> b; // (K), legal
typename template    X<int> c; // (L), ill-formed

^{注意：应用typename或模板在不需要的上下文中被视为好练习;仅仅因为您可以做某事，并不意味着您应该做。}

此外，在某些情况下，typename和template是明确禁止：

• 指定类继承的基础

  在派生类的 base-specifier-list 中编写的每个名称已经被视为 type-name ，明确指定typename均为形成不良和多余的。

    // .---------基本列表列表
    t＆gt; lt; lt; lt; // v
    struct派生：typename wory wory＆lt; t＆gt; :: type / *＆lt;  - 不构型 * / {
      ...
    };
   

• 当 template-id 是使用指导性

  中引用的

    struct base {
      t＆gt; lt; lt; lt;
      struct类型{};
    };
  
    结构派生：基础{
      使用base ::模板类型; //不构造
      使用base ::类型; // 合法的
    };
   

Answer 8

_{这个答案是一个相当简短而甜蜜的答案，可以回答标题为“问题的一部分”。如果您想提供更多详细的答案，以解释为什么必须将它们放在那里，请访问在这里。}

---

放置typeName关键字的一般规则主要是在使用模板参数时，并且要访问嵌套typedef或使用-Alias，for for示例：

template<typename T>
struct test {
    using type = T; // no typename required
    using underlying_type = typename T::type // typename required
};

请注意，这也适用于元功能或采用通用模板参数的事物。但是，如果提供的模板参数为显式类型，则不必指定typename，例如：

template<typename T>
struct test {
    // typename required
    using type = typename std::conditional<true, const T&, T&&>::type;
    // no typename required
    using integer = std::conditional<true, int, float>::type;
};

添加template vilifier的常规规则大多相似它们通常涉及本身被模板的结构/类的模板成员函数（静态或其他），例如：

给定此结构和功能：

template<typename T>
struct test {
    template<typename U>
    void get() const {
        std::cout << "get\n";
    }
};

template<typename T>
void func(const test<T>& t) {
    t.get<int>(); // error
}

尝试从内部访问t.get＆lt; int＆gt;（）该函数将导致错误：

main.cpp:13:11: error: expected primary-expression before 'int'
     t.get<int>();
           ^
main.cpp:13:11: error: expected ';' before 'int'

，在此上下文中，您需要事先调用template关键字，然后将其称为：

t.template get＆lt; int＆gt;（）

因此 编译器将正确解析此而不是t.get＆lt; int。

Answer 9

typedef typename Tail::inUnion<U> dummy;

但是，我不确定您的实现是正确的。如果我正确理解，则不应该实例化此类，因此“失败”选项卡将永远不会失败。也许更好地指示该类型是否具有简单的布尔值。

template <typename T, typename TypeList> struct Contains;

template <typename T, typename Head, typename Tail>
struct Contains<T, UnionNode<Head, Tail> >
{
    enum { result = Contains<T, Tail>::result };
};

template <typename T, typename Tail>
struct Contains<T, UnionNode<T, Tail> >
{
    enum { result = true };
};

template <typename T>
struct Contains<T, void>
{
    enum { result = false };
};

PS：看看

” ：看看 Typelists ，特别是在Andrei Alexandrescu的书中：

Answer 10

c ++ 20 aka c ++ 2a

如此提案，C ++ 20/C ++ 2A进一步放松了typename关键字的要求。特别是，typeName现在可以在所有这些位置省略，在句法上只有类型是合法的。因此，如果未知令牌必须是一种类型，则C ++ 20实际上将其视为一种类型。对于向后兼容，typename仍可以使用。

特别是，使用和typedef声明的大多数现在可以编写typename。 typename也可以在方法返回类型的声明（包括尾声返回类型），方法和lambda参数的声明以及类型参数中省略static_cast，<代码> const_cast，dynamic_cast和reinterpret_cast。

一个值得注意的例外是typeName仍然需要的是在用户或库的实例化的参数列表中：即使，如果该特定参数被声明为一种类型，则typeName < /代码>仍然需要关键字。 SO static_cast＆lt; a :: b＆gt;（arg）在C ++ 20中是合法的，但是my_template_class＆lt; a :: b＆gt;（arg gt）是错误的，如果a是依赖范围，my_template_class期望类型。

一些例子：

class A { public: typedef int type; static const int val { 1 }; };
class B { public: typedef float type; static const int val { 2 }; };
template<typename T> class C {};
template<int I> class D {};
template<typename T> class X {
    T::type v;                                  // OK
    T::type f(T::type arg) { return arg; }      // OK
    T::type g(double arg) { return static_cast<T::type>(arg); } // OK
    // C<T::type> c1;                           // error
    D<T::val> d;                                // OK (as has always been)
    C<typename T::type> c2;                     // OK (old style)
    typedef T::type mytype;                     // OK
    using mytypeagain = T::type;                // OK
    C<mytype> c3;                               // OK (via typedef / using)
};
X<A> xa;
X<B> xb;