每个C或C++文件都应该有一个关联的头文件吗？

Question

是否每个.C或.cpp文件都应该有一个标题(.h)文件？

假设有以下C文件:

1. MAIN.C

2. Func1.C

3. Func2.C

4. Func3.C

其中,main()在MAIN.C文件.应该有四个头文件

1. Main.h

2. Func1.h

3. Func2.h

4. Func3.h

或者所有.C文件应该只有一个头文件？

什么是更好的方法？

Answer 1

main.h因为在编译时通常没有任何东西需要暴露给其他编译单元,所以这是不寻常的.main()本身需要为链接器/启动代码公开,但它们不使用头文件.

每个C文件可以有一个头文件,或者很可能是相关C文件组的头文件.

其中一个例子是,如果你有一个BTree实现,并且你已经在他们自己的C文件中添加,删除,搜索等,以最大限度地减少代码更改时的重新编译.

在这种情况下,为每个C文件分别具有单独的头文件是没有意义的,因为头是API,即用户的库视图.我怀疑用户是否希望包含6个头文件才能使用这些功能.将有一个btree.h文件和一个btree.lib文件包含从各个C文件构建的所有BTree对象.

另一个例子可以在标准C头中找到.我们不确定这些stdio.h函数是否有多个C文件(这就是我怎么做但它不是唯一的方法)但是,即使有,它们也被视为API的一个单元.您不必包含stdio_printf.h,stdio_fgets.h等等 - stdio.hC运行时库的标准I/O部分有一个单独的部分.

Answer 2

1. 头文件不是必需的.

2. #include 只需复制/粘贴包含的任何文件(包括.c源文件)

3. 在现实生活项目中常用的是全局头文件config.h,constants.h它们包含常用信息,如编译时标志和项目范围常量.

4. 一个好的库API设计是用一组头文件公开一个官方接口,并使用一组内部头文件来实现所有细节.这为C库增加了一个很好的额外抽象层,而不会增加不必要的膨胀.

5. 使用常识.C/C++并不是没有它的人.

Answer 3

我曾经遵循"依赖"的趋势,直到我意识到一致性,一致性和简单性比节省创建文件的努力更重要,并且"即使它们很糟糕,标准也很好".

我的意思如下:.cpp/.h对文件几乎就是所有"模块"最终的结果.使两者都成为一项要求可以节省大量的混乱和糟糕的工程.

例如,当我在头文件中看到某些东西的界面时,我确切地知道在哪里搜索/放置它的实现.相反,如果我需要公开之前隐藏在.cpp文件中的东西的界面(例如静态函数变为全局),我就知道确切地放置它的位置.

我已经看到了不遵循这个简单规则的太多不良后果.不必要的内联函数,打破任何关于封装的规则,(非)分离接口和实现,错位的代码,仅举几例 - 所有这些都归因于从未添加适当的兄弟头或cpp文件.

所以:始终定义.h和.c文件.使其成为标准,遵循它,并安全地依赖它.生活这种方式简单得多,简单是软件中最重要的事情.

Answer 4

通常，最好为每个 .c 文件都有一个头文件，其中包含要公开的 .c 文件中函数等的声明。这样，另一个 .c 文件可以包含它需要的函数的 .h 文件，如果它不包含的头文件被更改，则不需要重新编译。

Answer 5

一般每个.c/.cpp文件都会有一个.h文件。