关于“丢失;在X之前”级联错误,我该怎么办?

时间:2016-05-23 12:51:43

标签: c++

我不确定我做错了什么,但突然我的C ++项目在该项目的某些部分中为每一行头文件抛出错误。其中一个文件肯定有问题,但我怎么知道这100个错误中哪一个是相关的呢?

日志看起来像:

5>d:\ ... PROJECT_HOME ... \services\src\services\database\techcore\processes\inputdialog\../import/ImportDataSource.h(10): error C2143: syntax error : missing ',' before ')'
5>d:\ ... PROJECT_HOME ... \services\src\services\database\techcore\processes\inputdialog\../import/ImportDataSource.h(16): error C3861: 'mapping_': identifier not found
5>d:\ ... PROJECT_HOME ... \services\src\services\database\techcore\processes\inputdialog\../import/ImportDataSource.h(17): error C2143: syntax error : missing ',' before '{'
5>d:\ ... PROJECT_HOME ... \services\src\services\database\techcore\processes\inputdialog\../import/ImportDataSource.h(17): error C2143: syntax error : missing ';' before '{'
5>c:\qt\5.3.0-64\qtbase\include\qtwidgets\../../src/widgets/kernel/qaction.h(162): error C2143: syntax error : missing ';' before '{'
5>c:\qt\5.3.0-64\qtbase\include\qtwidgets\../../src/widgets/kernel/qaction.h(162): error C2065: 'Hover' : undeclared identifier
5>d:\ ... PROJECT_HOME ... \services\src\services\database\techcore\processes\inputdialog\../import/ImportDataSource.h(30): error C2143: syntax error : missing ';' before '{'
5>c:\qt\5.3.0-64\qtbase\include\qtwidgets\../../src/widgets/kernel/qaction.h(177): error C2065: 'QGraphicsWidget' : undeclared identifier

我故意复制了错误也来自外部库的部分。编译器简直疯了。我该如何解决这个问题?如何找到导致此级联错误的位置?是否有一些验证器可以处理文件并给出一些提示?我手动浏览了大部分文件,看起来是正确的。

这不是第一次发生在我身上,所以我决定是时候问一下如何解决这些问题了。

1 个答案:

答案 0 :(得分:3)

通常,“编译器疯狂”是编译器遇到大量错误的症状,在受影响的源文件(也称为编译单元)中仍有更多代码需要处理。

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

解决这个问题的方法很简单 - 找到并纠正编译器发出的第一个诊断,而不是最后一个。如果错误消息与多个头文件相关联并不重要 - 在预处理之后,编译器按顺序处理代码,因此它报告的第一个错误消息是它找到的第一个错误消息。

许多开发人员 - 而不仅仅是初学者 - 从大屏幕诊断(或者,例如,可滚动窗口)的底部开始,然后处理屏幕。这有效地从编译器发出的最后一个诊断开始,而不是第一个 - 编译器最可能混淆的一个点,并发出与代码关系不大的诊断。相反,有必要向上滚动屏幕,找到第一个发布的诊断,并首先解决。

某些编译器支持在指定数量的错误后停止编译的选项。这些选项可用于限制报告的错误数量,从而减少混淆错误消息的可能性。但是,这通常只是部分有效,因为没有关于引发编译器混淆的错误数量的硬性规则。如上所述,真正的解决方案是养成查找第一条错误消息并解决该问题的习惯,而不是尝试从上一条错误消息中向后工作。