在 C++ 中使用尖括号会带来哪些语法问题？模板？

Question

在 C++ 中，模板使用尖括号 vector 进行实例化，Java 和 C# 语言对其泛型采用了相同的语法。

然而，D 的创建者对于尖括号带来的问题直言不讳，他们制定了一种新语法 foo!(int) ——但我从未见过太多关于尖括号带来的问题的细节确切地说，括号带来。

其中之一是用另一个模板 vector> 实例化一个模板时，这会导致某些（较旧的？）编译器将尾随 '>>` 与位混淆移位或流式运算符。解决方案是在两个尖括号之间插入一个空格，但是现在编译器还不能解析该语法吗？

另一个问题是使用大于运算符 foo<3> 时。 2>。解析器会认为该操作符实际上关闭了模板实例化；修复方法是引入括号 foo<(3 > 2)>。但我认为在很多情况下您都不需要这样做，无论如何，我宁愿在需要时输入额外的括号，而不是引入新的语法并且总是 必须输入感叹号。

尖括号还有哪些其他问题促使 D 开发人员创建新语法？

Answer 1

就我个人而言，我见过的最可怕的问题是在依赖上下文中调用模板函数：

template <typename T>
void foo(T t) {
  t.bar<3>();
}

这看起来确实很简单，但实际上是不正确的。 C++ 标准要求引入 template 关键字来消除 t.bar t.bar 的歧义。 3 与方法调用屈服：

t.template bar<3>(); // iirk

litb 发表了一些关于编译器可能提出的可能解释的非常有趣的帖子。

关于 >> 问题，它已在 C++0x 中修复，但需要更聪明的编译器。

Answer 2

但是现在编译器还不能解析该语法吗？

当然。但这绝非小事。特别是，它阻止您在上下文无关的词法分析器和解析器之间实现清晰的分离。对于语法荧光笔和其他需要解析 C++ 但不希望/无法实现成熟的语法分析器的支持工具来说，这尤其令人厌烦。

它使 C++ 变得更加难以解析，以至于很多工具根本不会打扰。这是生态系统的净损失。换句话说：它使得开发解析工具变得更加昂贵。

例如，ctags 对于某些模板定义失败，这使得它无法在我们当前的 C++ 项目中使用。很烦人。

但我认为在很多情况下您不需要[区分尖括号和小于号]

您需要这样做的频率并不重要。您的解析器仍然需要处理这个问题。

D 放弃角背的决定是理所当然的。任何一个理由都足够了，因为它是一项净收益。

Answer 3

问题在于使语言语法与上下文无关。当词法分析器对程序进行标记时，它使用一种名为 maximal munch 的技术，这意味着它总是采用可以指定标记的最长字符串。这意味着 >> 被视为正确的位移运算符。因此，如果您有类似 vector> 的内容，则末尾的 >> 会被视为正确的位移运算符，而不是部分模板实例化。为了让它在此上下文中以不同的方式对待 >>，它必须是上下文敏感的，而不是上下文无关的 - 也就是说，它具有真正关心正在解析的标记的上下文。这使得词法分析器和解析器变得相当复杂。词法分析器和解析器越复杂，出现错误的风险就越高，更重要的是，工具实现它们的难度越大，这意味着工具就越少。当 IDE 或代码编辑器中的语法突出显示之类的东西实现起来变得复杂时，就会出现问题。

通过使用 !() - 这将导致相同声明的 vector!(pair!(int, int)) - D 避免了上下文敏感性问题。 D 在其语法中明确地做出了许多这样的选择，其目的是让工具在需要时更容易实现词法分析或解析，以便完成它们所做的事情。而且，由于对模板使用 !() 确实没有什么缺点，除了对于在其他使用 <>< 的语言中使用过模板或泛型的程序员来说有点陌生。 /code>，这是一个合理的语言设计选择。

在使用尖括号语法时，您使用或不使用模板的频率会产生歧义 - 例如 vector> - 与语言并不真正相关。无论如何，工具必须实现它。使用 !() 而不是 <> 的决定完全是为了简化工具的语言，而不是为了程序员。尽管您可能特别喜欢也可能不特别喜欢 !() 语法，但它非常易于使用，因此除了学习它之外它最终不会给程序员带来任何问题，并且事实上它可能违背他们的习惯个人喜好。

Answer 4

在 C++ 中，另一个问题是预处理器不理解尖括号，因此会失败：

#define FOO(X) typename something<X>::type

FOO(std::map<int, int>)

问题是预处理器认为 FOO 正在使用两个参数调用：std::map 和 int>。这是一个更广泛问题的示例，即符号是运算符还是括号通常是不明确的。

Answer 5

弄清楚它的作用很有趣：

bool b = A< B>::C == D<E >::F();
bool b = A<B>::C == D<E>::F();

上次我检查时，您可以通过更改范围内的内容来使其以任何一种方式进行解析。

使用 < 和 > 作为匹配和非匹配标记是一场灾难。至于 !() 使 D 使用时间更长：对于具有单个参数的常见情况，() 是可选的，例如这是合法的：

Set!int foo;

Answer 6

我相信这些是唯一的案例。

然而，与其说这是一个用户问题，不如说它是一个实现者问题。这种看似微不足道的差异使得为 C++ 构建正确的解析器变得更加困难（与 D 相比）。 D 还被设计为对实现者友好，因此他们尽力避免产生不明确的代码。

（旁注：我确实发现shift-感叹号组合有点尴尬......尖括号的一个优点绝对是易于打字！）

Answer 7

>= 大于或等于歧义 是另一种未提及的情况：

失败：

template <int>
using A = int;
void f(A<0>=0);

有效：

void f(A<0> =0);

我认为这在 C++11 中并没有像 >>.

有关更多详细信息，请参阅此问题： 为什么“A<0>=”中的 template-id 0" 由于大于或等于运算符“>=”，没有空格就无法编译？

Answer 8

最终，任何编译器都必须将您的半英语源代码（无论何种语言）转换为计算机可以实际操作的真实机器代码。这最终是一系列极其复杂的数学变换。

嗯，数学告诉我们，编译所需的映射是“到”或“满射”。这意味着每个合法程序都可以明确地映射到汇编。这就是语言关键字和标点符号“;”的含义。存在的原因以及为什么每种语言都有它们。然而，像 C++ 这样的语言使用相同的符号，如“{}”和“<>”对于多个事物，因此编译器必须添加额外的步骤来生成整体，并转换它需要的内容（这就是当您乘以矩阵时在线性代数中所做的事情）。这会增加编译时间，引入显着的复杂性，其本身可能包含错误，并且会限制编译器优化输出的能力。

例如，Strousoup 可以使用“@”作为模板参数 - 这是一个未使用的字符，非常适合让编译器知道“这是并且永远都是某种模板”。这实际上是一对一的转换，非常适合分析工具。但他没有；他使用了已经映射到大于和小于的符号。仅此一点就立即引入了歧义，而且只会变得更糟。

听起来“D”决定将序列“！（）”作为一个特殊符号，仅用于模板，就像上面的“@”示例一样。我愿意猜测其高度模板化的代码编译速度更快并且错误更少。