C++与 D 、 Ada 和 Eiffel （带有模板的可怕错误消息）

Question

C++ 的问题之一是我们从大量使用模板和模板元编程的代码中收到可怕的错误消息。这些概念旨在解决这个问题，但不幸的是它们不会出现在下一个标准中。

我想知道，这个问题对于所有支持泛型编程的语言来说都是常见的吗？或者 C++ 模板有问题？

不幸的是，我不知道任何其他语言支持泛型编程（Java 和 C# 泛型过于简化，而且不如 C++ 模板强大）。

所以我问你们：D、Ada、Eiffel 模板（泛型）也会产生如此丑陋的错误消息吗？是否有可能有一种语言具有强大的通用编程范式，但没有丑陋的错误消息？如果是，这些语言是如何解决这个问题的？

编辑：针对投反对票的人。我真的很喜欢 C++ 和模板。我并不是说模板不好。事实上，我非常喜欢泛型编程和模板元编程。我只是问为什么我会从编译器收到如此难看的错误消息。

Answer 1

Eiffel 拥有所有错误消息中最好的，因为它拥有所有模板系统中最好的。它完全集成到语言中并且运行良好，因为它是唯一在参数中使用 covarianz 的语言。

因此，它不仅仅是简单的编译器复制和粘贴。不幸的是，用几行代码来解释差异是不可能的。去 EiffelStudio 看看吧。

Answer 2

有一些努力来改进错误消息。例如，Clang 非常重视生成更易于阅读的编译器错误消息。我只使用了很短一段时间，但到目前为止，与 GCC 的同等错误相比，我对它的体验非常积极。

Answer 3

问题的核心在于，无论在什么情况下，错误恢复都很困难。

当您考虑到 C 和 C++ 可怕的语法时，您只能想知道错误消息并不比这更糟糕！恐怕 C 语法是由那些对语法的基本属性一无所知的人设计的，其中之一是对上下文的依赖越少越好，另一个是您应该努力使它尽可能明确。

让我们举例说明一个常见错误：忘记分号。

struct CType {
  int a;
  char b;
}
foo
bar() { /**/ }

好吧，这是错误的，缺少的分号应该去哪里？不幸的是，它是不明确的，它可以在 foo 之前或之后，因为：

• C 认为在定义 struct 后以 stride 声明变量是正常的
• C 认为不指定是正常的函数的返回类型（在这种情况下，它默认为 int）

如果我们推理，我们可以看到：

• 如果 foo 命名了一个类型，那么它属于函数声明
• 如果不是，它可能表示一个变量...当然，除非我们犯了一个拼写错误，并且它本来应该写成fool，它恰好是一个类型：/

如你所见，错误恢复是非常困难的，因为我们需要推断作者的意思，而语法远不能被接受。但这并非不可能，而且大多数错误确实可以或多或少正确地诊断出来，甚至可以从中恢复......这只需要相当大的努力。

似乎从事 gcc 工作的人更感兴趣的是生成快速代码（我的意思是快速，搜索 gcc 4.6 上的最新基准）和添加有趣的功能（gcc 已经实现大部分（如果不是全部）C++0x）而不是生成易于阅读的错误消息。你能责怪他们吗？我不能。

幸运的是，有人认为准确的错误报告和良好的错误恢复是一个非常有价值的目标，其中一些人已经在 CLang 上工作了相当长的时间，并且他们将继续这样做。

一些不错的功能，在我的脑海中浮现出来：

• 简洁但完整的错误消息，其中包括源范围，以准确暴露错误源自
• Fix-It 的注释，当它的含义很明显
• 时编译器会解析文件的其余部分，就好像修复已经存在一样，而不是在乱码行上喷出一行又一行
• （最近的），避免包含注释的包含堆栈，以删除多余的内容
• （最近的），只尝试暴露开发人员实际编写的模板参数类型，并保留 typedef（因此讨论 std::vector 而不是 std::vector>、std::allocator> > 使一切变得不同）
• （最近）在丢失的情况下正确恢复template 以防在从另一个模板方法调用模板方法时丢失该模板

但是每个模板方法都需要几个小时到几天的工作。

他们当然不是免费来的。

现在，概念（通常）应该让我们的生活变得更轻松。但他们大多未经测试，因此最好将他们从选秀中删除。我必须说我对此感到高兴。考虑到 C++ 的相对惯性，最好不要包含尚未彻底修改的功能，而且概念图并没有真正让我兴奋。他们似乎也没有让 Bjarne 或 Herb 感到兴奋，因为他们表示将重新考虑下一个标准的概念。

Answer 4

一般来说，我发现泛型的 Ada 编译器错误消息实际上并不比任何其他 Ada 编译器错误消息更难阅读。

另一方面，C++ 模板错误消息因 错误小说。我认为主要区别在于 C++ 进行模板实例化的方式。事实是，C++ 模板比 Ada 泛型灵活得多。它非常灵活，几乎就像一个宏预处理器。 Boost 中的聪明人已经使用它来实现诸如 lambda 之类的东西，甚至整个其他语言。

由于这种灵活性，每次第一次遇到模板参数的特定排列时，基本上都必须重新编译整个模板层次结构。因此，解决 API 下几层不兼容性的问题最终会呈现给糟糕的 API 客户端来解密。

在 Ada 中，泛型实际上是强类型的，并向客户端提供完整的信息隐藏，就像普通的包和子例程一样。因此，如果您确实收到一条错误消息，它通常只是引用您尝试实例化的一个泛型，而不是用于实现它的整个层次结构。

所以，是的，C++ 模板错误消息比 Ada 的错误消息要糟糕得多。

现在调试完全是一个不同的故事......

Answer 5

文章泛型编程概述了泛型的许多优点和缺点多种语言，包括特别是 Ada。尽管缺乏模板专业化，但所有 Ada 通用 < a href="http://www.adaic.org/resources/add_content/standards/05rm/html/RM-12-3.html" rel="noreferrer">实例“相当于实例声明…紧接着是实例主体”。实际上，错误消息往往发生在编译时，它们通常代表常见的类型安全违规行为。

Answer 6

D 有两个功能可以提高模板错误消息的质量：约束和静态断言。

// Use constraints to only allow a function to operate on random access 
// ranges as defined in std.range.  If something that doesn't satisfy this
// is passed, the compiler will error before even trying to instantiate
// fun().
void fun(R)(R range) if(isRandomAccessRange!(R)) {
    // Do stuff.
}


// Use static assert to check a high level invariant.  If 
// the predicate is false, the error message will be 
// printed and compilation will stop before a screen 
// worth of more confusing errors are encountered.
// This function takes any number of ranges to merge sort
// and the same number of temporary buffers to merge into.
void mergeSort(R...)(R ranges) {
    static assert(R.length % 2 == 0, 
        "Must have equal number of ranges to be sorted and temporary buffers.");

    static assert(allSatisfy!(isRandomAccessRange, R), 
        "All arguments to mergeSort must be random access ranges.");

    // Implementation
}