在第一个错误之后，您是否阅读C或C ++编译错误？

我从来不明白为什么C和C ++编译器会尝试从错误中恢复并继续解析。几乎总是，第一个错误会生成一系列伪错误，这些错误会在第一个错误修复后立即消失。经过几年的经验，我只是停止查看除每个文件的第一个错误以外的任何错误。我重新运行编译器，然后再次执行该操作，直到没有更多错误为止。这是常见的做法吗？

有时错误是无关的。我发现查看错误列表并修复一系列相关错误的根本原因，然后修复下一个不相关的错误，会更容易。如果项目很大并且需要一些时间来构建，那么我发现以这种方式进行的工作比修复第一个错误，重新编译，重复进行的工作更令人沮丧。

这取决于编译时间。例如，如果我知道我刚刚更改了将触发整个项目重建的主标头，那么我一定会仔细研究一下错误堆栈的其余部分，看看是否可以修复其中的一些错误。当我在编译器运行时站起来煮咖啡时，这给了我更好的感觉。

是的，我会这样做，除非我使用编译器来帮助我重构，在这种情况下，我喜欢完整的错误列表:)

如果行号之间存在间隙，则编译器可能确实恢复了，然后发现了另一个错误。

通常，通常只尝试修正每个错误中的一个错误。

更好的编译器会产生更好的结果，并在第一个错误之后给出更多有用的错误，通常通过某种方式对错误进行自动纠正，以便至少可以检查良好的代码。但是后来，我习惯了在Eclipse中使用Java进行工作，在Java中，可以立即检测并轻松纠正语法错误，并且其他编译器错误往往更加多样化并且更容易从编译器中恢复。我只能假设在Microsoft的IDE和其他使用C ++或C＃的IDE中工作时，它们是相似的。

是的-至少我会略过它们。很容易弄清楚这些错误是否相关（通常看一下行号就足够了），我喜欢一次性修复所有错误然后重新编译。

仅当1 cpp编译时间很长时，我才这样做（以读取第一个错误之后的错误）。还是不可用。然后，我更喜欢确保我将在编译器错误中可以识别的所有错误都与第一个错误无关。

当您的cpp文件可以被单独编译并且在不到一秒钟的时间内完成编译（或者甚至在编译开始之前就出现了“智能”指向错误）时，您就不必在大多数时间这样做。

我目前在一个无法单独编译一个cpp的项目（并且我没有构建系统的知识，所以我无法更改O__o），并且某些cpp文件可能需要十多分钟才能编译（即使经过大量努力来减少这种情况，我们也只将其减少了原始编译时间的50％...）。

在这种非常长的编译设置中，您倾向于在遇到“ build”之前先思考很多，甚至在思考之后再思考很多，以便在编译器之前发现错误，因为您肯定比在头脑中更快地找到它们。 。

做起来很普遍。我通常会告诉实习生或新手程序员，他们对错误的数量感到不知所措，以忽略除第一个错误以外的几乎所有错误。这很可能是一个需要修复的实际错误，而不是由前一个错误引起的误导性幻像错误。由于某些原因，某些（大多数？）编译器可以选择在出现第一个错误之后停止编译。通常，可以将构建系统配置为在第一个有错误的文件之后停止。

但是，也有理由在检测到错误后仍继续编译。例如，您可能要计算有多少个文件出错，或者要查看包含的头文件是否在多个文件中引起错误。