c++ - QT 类型被外部库定义为 int？

Question

我正在将一个项目集成到另一个项目中，并且遇到了一些 QT 构建问题。
我得到的问题是在声明 QMetaType::Bool 的 moc 文件中生成了一行。
它说“'int'之前的预期不合格ID”，然后是由该错误引起的几个括号错误。
根据我的研究，其他人说这是由于项目中将 Bool 定义为 int 的其他地方的 xlib.h。
我已经尝试过“#undef Bool”行，但它似乎不起作用。当我将它放在调用堆栈中最近的 cpp 文件的标题中时，上面提到的错误消失了，但它也破坏了我在所述 cpp 文件中声明的所有对象，给了我一堆 undefined reference 错误，我知道不是真的。
所以两个问题:

尽管我显式地调用了 QMetaType::命名空间，但为什么在从不同的库中获取不同的 Bool 定义时会出现错误？

有其他解决此问题的方法的想法吗？

编辑:这是在 moc 文件中导致问题的功能 block 。

#undef QT_MOC_LITERAL

static const uint qt_meta_data_FUNCTIONNAMEREDACTED[] = {

 // content:
       7,       // revision
       0,       // classname
       0,    0, // classinfo
       6,   14, // methods
       0,    0, // properties
       0,    0, // enums/sets
       0,    0, // constructors
       0,       // flags
       0,       // signalCount

 // slots: name, argc, parameters, tag, flags
       1,    0,   44,    2, 0x0a /* Public */,
       3,    1,   45,    2, 0x0a /* Public */,
       5,    1,   48,    2, 0x0a /* Public */,
       6,    0,   51,    2, 0x0a /* Public */,
       7,    1,   52,    2, 0x0a /* Public */,
       9,    1,   55,    2, 0x0a /* Public */,

 // slots: parameters
    QMetaType::Void,
    QMetaType::Void, QMetaType::Int,    4,
    QMetaType::Void, QMetaType::Int,    4,
    QMetaType::Void,
    QMetaType::Void, QMetaType::Bool,    8,
    QMetaType::Void, QMetaType::QString,   10,

       0        // eod
};

Answer 1

C preprocessor在 C++ 中是从 C 的继承。
粗略地说，它提供了超越(之前)编译器精确句法分析的文本替换。 (cppreference.com – Phases of translation)
因此，预处理器是 namespace不可知论，这在 C 中不是问题(像 namespace 这样的东西根本不存在)，但它可能会在 C++ 中引起奇怪的影响。
虽然我第一次听说 xlib.h 的问题，这是关于 windows.h 的常见奇怪问题的来源(广泛使用宏在 API 函数的 ASCII 和 Unicode 风格之间切换)。
预处理的中间结果通常直接输入到后面的编译器阶段，以便作者不会立即看到意外的替换。
然而，每个 C 和 C++ 编译器都提供了一个仅预处理器运行的选项，该运行发出生成的 C 或 C++ 源代码。因此，如果出现像 OP 这样的奇怪且难以解释的错误，可能值得至少访问发生错误的 C++ 源的预处理源文件。
(即使头文件报错，也必须追溯到源文件，因为#include也是预处理的对象。)
这些预处理文件可能会变得非常大，因为许多标准和/或系统头文件也可能(间接地)包含在内，从而导致单个 C++ 源文件有数千行。
另一种选择是启用有关包含的 header 的诊断输出。
对于 MSVC++，resp。选项是 /showIncludes .默认情况下通常禁用此选项，因为即使仅列出包含的内容通常也会导致冗长且不方便的诊断输出。

一旦一个宏(在直接或间接包含的头文件中定义)被确定为问题的根源，就可以考虑如何解决这个问题。
主要有两种选择:

更改#include的顺序小号

#undef相应的。相关 #include 之后的宏或至少在最后一个 #include 之后在这个源文件中。

这必须在每个相关的 C++ 源文件中完成。
它也可以在标题中完成，但这很容易出错，我不推荐这样做。原因很简单:
宏可能被定义、未定义、再次定义，实际执行的方式取决于确切的顺序，文件由编译器“看到”。
对于 C++ 源文件，这很清楚，因为它是 translation unit在其自己的。
相反， header 可能包含在其他 header 之前或之后的各个位置，这在 header 本身编写时很难预测。