为什么 "A<0>=0" 中的模板 ID 在没有 space 的情况下无法编译,因为大于或等于运算符“>=”?

Why does the template-id in "A<0>=0" not compile without space because of the greater-or-equal-than operator ">="?

template <int>
using A = int;

void f(A<0>=0);   // Attempting to declare a function f taking int,
                  // with the default argument 0

// Works as expected:
// void f(A<0> = 0);

这既不能在 GCC 4.9.2 nor Clang 3.5 上编译 - 更不用说 ICC 或 VC++ 了。显然 >= 位被解析为大于或等于运算符。但是,关于 [temp.names]/3:

这似乎是不正确的

After name lookup (3.4) finds that a name is a template-name or that an operator-function-id or a literal- operator-id refers to a set of overloaded functions any member of which is a function template, if this is followed by a <, the < is always taken as the delimiter of a template-argument-list and never as the less-than operator. When parsing a template-argument-list, the first non-nested >138 is taken as the ending delimiter rather than a greater-than operator. [..] [ Example:

template<int i> class X { /* ...*/ };

X< 1>2 > x1; // syntax error
X<(1>2)> x2; // OK

— end example ]

138) A > that encloses the type-id of a dynamic_cast, static_cast, reinterpret_cast or const_cast, or which encloses the template-arguments of a subsequent template-id, is considered nested for the purpose of this description.

我是不是遗漏了什么或者这是一个编译器错误?

这是 maximal munch principle 的一个效果,它让词法分析器采用尽可能多的字符来形成有效标记。这在草案 C++ 标准部分 2.5 [lex.pptoken] 中有说明:

Otherwise, the next preprocessing token is the longest sequence of characters that could constitute a preprocessing token, even if that would cause further lexical analysis to fail.

任何情况,例如您上面引用的情况,都需要一个特定的例外,例如 <:: 的这种情况,我们可以在以下代码中看到一个示例:

template<typename T> class SomeClass;
class Class;

SomeClass<::Class>* cls;

已在 this question 中介绍,最大咀嚼规则正上方的项目符号中列出了例外情况:

Otherwise, if the next three characters are <:: and the subsequent character is neither : nor >, the < is treated as a preprocessor token by itself and not as the first character of the alternative token <:.

当然还有您在问题中引用的非嵌套 >

请注意,我们可以看到 >= 是来自 2.13 [lex.operators] 部分的预处理器标记,它表示:

The lexical representation of C++ programs includes a number of preprocessing tokens which are used in the syntax of the preprocessor or are converted into tokens for operators and punctuators:

并在列表中包含 >=

>>修复

我们可以从修复 >> 案例的提案中看到:N1757: Right Angle Brackets 上面写着 (emphasis mine):

Ever since the introduction of angle brackets, C++ programmers have been surprised by the fact that two consecutive right angle brackets must be separated by whitespace:

#include <vector>
typedef std::vector<std::vector<int> > Table;  // OK
typedef std::vector<std::vector<bool>> Flags;  // Error

The problem is an immediate consequence of the the “maximum munch” principle and the fact that >> is a valid token (right shift) in C++.

This issue is a minor, but persisting, annoying, and somewhat embarrassing problem. If the cost is reasonable, it seems therefore worthwhile to eliminate the surprise.

The purpose of this document is to explain ways to allow >> to be treated as two closing angle brackets, as well as to discuss the resulting issues. A specific option is proposed along with wording that would implement the proposal in the current working paper.

同时指出>=案例:

It is also worth noting that the problem can also occur with the >>= and >= tokens. For example

void func(List<B>= default_val1);
void func(List<List<B>>= default_val2);

Both of these forms are currently ill-formed. It may be desirable to also address this issue, but this paper does not propose to do so.

请注意,此更改 broke backward compatibility with C++03