头文件或实现文件中的#import

时间:2010-11-19 03:38:44

标签: c++ objective-c c coding-style

有些人习惯将头文件import / includes添加到头文件中。另一方面,在头文件中写一个前向声明,并在实现文件中写下实际的#include或#import行。

这是否有标准做法?哪个更好,为什么?

3 个答案:

答案 0 :(得分:10)

给定X.h和X.c,如果#include来自X.h的所有内容,那么{X}的客户端#include <X.h>也将包含所有这些头,即使有些可能只在X.c中需要。

X.h应该只包含解析X.h所需的内容。它应该假设翻译单元不会包含其他标题,以确保重新排序包含不会破坏客户端。 X.c应该包括实现所需的任何额外内容。

这可以最大限度地减少重新编译依赖性。您不希望仅对实现进行更改以影响标头,从而触发客户端重新编译。您应该直接从X.c。

中包含

答案 1 :(得分:2)

当类具有浅依赖性时,必须包含前向引用而不是头。例如:

<强> A.H

#include "B.h"
class A {
   B* pointer;
};

<强> B.h

#include "A.h"
class B {
   A* pointer;
};

将在编译时中断。

<强> A.H

class B;
class A {
   B* pointer;
};

<强> B.h

class A;
class B {
   A* pointer;
};

将工作,因为每个类只需要知道声明中存在另一个类。

答案 2 :(得分:0)

我在头文件中编写导入,因此每个实现文件只有一个包含指令。这也具有隐藏模块代码用户的依赖关系的优点。

然而,同样的隐藏有一个缺点:你的模块的用户可能正在导入你可能根本不需要的标题中包含的各种其他标题。从这个角度来看,最好在实现文件中包含包含指令,即使它意味着手动解析依赖关系,因为它会导致代码更轻。

我认为没有一个答案。考虑到我给出的原因,我更喜欢第一种方法,我认为它会导致更清晰的代码(虽然更重,可能还有不必要的进口)。

我不记得我在引用谁(因此这句话并不精确),但我总是记得读:“程序是为人类阅读而写的,并且是计算机执行的偶像”。我并不特别在意我的模块用户不需要几千字节的代码,只要他能干净利落,轻松导入并使用单一指令即可。

同样,我认为这是一个品味问题,除非我没有考虑到这一点。在这种情况下,评论非常受欢迎!

干杯。