我能做些什么"missing ; before X"一连串的错误？

What can I do about "missing ; before X" cascade of errors?

本文关键字：一连串 错误 做些什么 missing before      更新时间：2023-10-16

我不确定我做错了什么，但突然间，我的C++项目在该项目的某些部分的每一行头文件都会出错。其中一个文件肯定有问题，但我该如何找出这一百个错误中的哪一个是相关的？

日志看起来像：

5>d: ... PROJECT_HOME ... servicessrcservicesdatabasetechcoreprocessesinputdialog../import/ImportDataSource.h(10): error C2143: syntax error : missing ',' before ')'
5>d: ... PROJECT_HOME ... servicessrcservicesdatabasetechcoreprocessesinputdialog../import/ImportDataSource.h(16): error C3861: 'mapping_': identifier not found
5>d: ... PROJECT_HOME ... servicessrcservicesdatabasetechcoreprocessesinputdialog../import/ImportDataSource.h(17): error C2143: syntax error : missing ',' before '{'
5>d: ... PROJECT_HOME ... servicessrcservicesdatabasetechcoreprocessesinputdialog../import/ImportDataSource.h(17): error C2143: syntax error : missing ';' before '{'
5>c:qt5.3.0-64qtbaseincludeqtwidgets../../src/widgets/kernel/qaction.h(162): error C2143: syntax error : missing ';' before '{'
5>c:qt5.3.0-64qtbaseincludeqtwidgets../../src/widgets/kernel/qaction.h(162): error C2065: 'Hover' : undeclared identifier
5>d: ... PROJECT_HOME ... servicessrcservicesdatabasetechcoreprocessesinputdialog../import/ImportDataSource.h(30): error C2143: syntax error : missing ';' before '{'
5>c:qt5.3.0-64qtbaseincludeqtwidgets../../src/widgets/kernel/qaction.h(177): error C2065: 'QGraphicsWidget' : undeclared identifier

我有意复制错误也来自外部库的部分。编译器简直疯了。我该如何解决此问题？我如何找到导致这一连串错误的地方？是否有一些验证器可以处理文件并给mi一些提示？我手动浏览了大部分文件，它们似乎是正确的。

这不是我第一次遇到这种情况，所以我决定是时候问问如何普遍解决这些问题了。

通常，"编译器疯了"是编译器遇到大量错误的症状，在受影响的源文件(又名编译单元)中还有更多代码要处理。

当遇到问题时，大多数编译器会发出诊断，但会继续处理源文件，直到到达文件末尾。在编译器发出几次诊断之后，通常会出现一种情况，即它处于一种奇怪的状态，因此随后的诊断与正在处理的代码几乎没有关系。

解决这个问题的方法很简单——找到并更正第一个诊断编译器问题，而不是最后一个。错误消息是否与多个头文件关联并不重要——预处理后，编译器会按顺序处理代码，因此它报告的第一个错误消息是它发现的第一个。

相当多的开发人员——也不仅仅是初学者——从诊断的大屏幕(例如，滚动窗口)的底部开始，然后在屏幕上工作。这实际上是从编译器发布的最后一个诊断开始的，而不是第一个——编译器最有可能混淆这一点，并发布与代码几乎没有关系的诊断。相反，有必要向上滚动屏幕，找到发布的第一个诊断，并首先解决该问题。

某些编译器支持在出现指定数量的错误后停止编译的选项。此类选项可用于限制报告的错误数量，从而减少错误消息混乱的可能性。然而，这通常只是部分有效的，因为对于引发编译器混乱的错误数量没有硬性规定。正如我上面所说，真正的解决方案是养成找到第一条错误消息并解决它的习惯，而不是试图从最后一条错误消息向后处理。

相关文章：