被迫在Mac上对C++代码使用正向声明(使用Xcode）

Forced to use forward declarations for C++ code on Mac (using Xcode)

本文关键字：声明 使用 Xcode Mac 上对 C++ 代码 被迫      更新时间：2023-10-16

这是一个奇怪的问题，我想知道是否有其他人看到过。我们正在为Mac和PC编写跨平台C++代码，这只发生在Mac上。

假设我有一个类，其.h文件如下所示。

class X {
public:
    int _myValue;
    void myFunction();
}

我还有另一个类，它的.h文件如下：

#include "X.h"
class Y {
private:
     X _myObj;
}

这不会编译。我们得到一个错误，指示X未定义。解决方案是在Y.h文件中为X添加一个正向声明，例如：X类；

我们这样做已经有一段时间了，但现在我们遇到了效果不太好的情况。例如，如果我们有一个.h文件，该文件在.h文件中定义了一个templates方法，而该方法引用了另一个类中的方法，编译器对此一无所知。同样，如果我们引用了一个在包含的类中定义的枚举，编译器无法识别它（解决这个问题的方法是将枚举放在一个单独的.h文件中，它很好地处理了它）。

在编译.cpp文件时，编译器几乎没有从包含的.h文件中提取数据。

我只是想知道是否有人看到过这样的事情，或者有可能的调查途径。

非常感谢。。。

有一个通用的系统头文件X.h，它是X11窗口工具包的一部分。我建议更改头文件的名称，这样它就不会与任何系统头文件冲突。

您可以尝试更改编译器开关，迫使它在系统包含目录之前考虑包含头文件的目录，但这可能会付出更多的努力，也更脆弱。

对于第一个问题（类），正确的答案是使用正向声明。应避免在其他项目包含文件中包含项目包含文件。这可以创建包含循环（如果我不得不猜测的话，这很可能是您的问题）。当您修改标头时，它还会造成过多的构建混乱。

对于其他问题（枚举、模板），这通常是由于包含周期。通过尽可能避免包含来打破这些周期是你的最佳选择。

有关此问题和最佳实践的更多讨论，请参阅typedefs的头文件最佳实践。

我只是有点惊讶，没有其他人提到包含文件的规范方案，例如

foo.h:

#ifndef FOO_H
#define FOO_H
// body of the include file
#endif

我怀疑在这个特定的情况下，"x.h"answers"x.h"的冲突可能是你看到的问题，但如果你不这样保护包含文件，它最终会咬你一口。

有了这个保护，你可以在任何需要的地方包含"x.h"。

相关文章：