我应该，还是不应该在不同的c文件中包含相同的头文件?

I'm building a main.c file to make use of functions out of a few different .h files. A few of those .h files (or rather, their .c source files) use the same includes (the standard but also some others like )

我建立一个主要。c文件使用一些不同的。h文件的函数。其中的一些.h文件(或者更确切地说，它们的.c源文件)使用了相同的include(标准的，但也有一些类似的)

My question is: Is it okay if I just include those once for all header files in my main.c, or should I let every .h file include them individually and not include them in my main.c (considering I only use functions from those header files)?

我的问题是:如果我只在主文件中包含一次头文件，可以吗?还是应该让每个.h文件单独包含它们，而不包含在我的main中。c(考虑到我只使用那些头文件中的函数)?

Or should I do both?

或者我应该两者都做?

How I do it now is:

我现在的做法是:

dist.c:

#include "dist.h"
#include  <stdio.h>
#include  <unistd.h>
#include  "rpiGpio.h"
#include <pthread.h>
#include  <wiringPi.h>
#include  <softPwm.h>

Then for another:

然后另一个:

cmps.c:

#include "cmps.h"
#include <stdint.h>
#include <stdio.h>
#include <unistd.h>
#include <math.h>
#include "rpiGpio.h"

Then in my main.c:

然后在我的c:

#include    <stdio.h>
#include    <stdlib.h>
#include    "dist.h"
#include    "cmps.h"

Thanks in advance!

提前谢谢!

2 个解决方案

#1

You should include standard headers above your own headers, and you should include all the dependencies for a file in that file. If you change the includes in one of your file, it shouldn't affect any other files. Each file should maintain its own list of header dependencies.

您应该在自己的头文件之上包含标准头文件，并且应该在该文件中包含文件的所有依赖项。如果您更改了一个文件中的include，那么它不应该影响任何其他文件。每个文件都应该维护自己的头依赖项列表。

If, in your example, dist.h includes <stdio.h>, you should not rely on this outside dist.h. If you change dist.h so that it no longer depends on <stdio.h> and remove that #include, then your program breaks.

在您的示例中，If .h包含 ，你不应该依赖于它。如果您改变了dist.h，使它不再依赖于 并删除#include，然后程序中断。 。h> 。h>

#2

I think the answer is "it depends". So long as you are consistent, I think it's OK. Some advantages and disadvantages of different approaches:

我认为答案是“视情况而定”。只要你坚持不懈，我认为没问题。不同方法的一些优缺点:

1. Including a system header twice will not cause adverse effects (due to header guards); including your own headers twice should also not cause problems provided you use header guards too. However, arguably it may slow compilation.

   包括一个系统头两次不会造成不良影响(由于头保护);如果您也使用了header警卫，那么两次包含您自己的header也不会导致问题。然而，可以说它可能会减慢编译速度。

2. In some circumstances, particularly on older Unices, the order of inclusion of headers matters (sadly). Sometimes the order of #defines (e.g. #define _GNU_SOURCE) does matter with respect to #include. I've also had this happen with Linux include files for various internal bits of networking (I now forget what). For this reason, it's a good idea to always include your system includes (and the #defines they examine) in a consistent manner.

   在某些情况下，特别是在较老的Unices上，包含头的顺序很重要(遗憾的是)。有时，#define的顺序(例如#define _GNU_SOURCE)与#include是相关的。我在Linux包含用于各种网络内部比特的文件时也遇到过这种情况(我现在忘记了什么)。出于这个原因，最好始终以一致的方式包含您的系统include(以及它们检查的#define定义)。

3. One way to do that is to put all your system includes in a single include file of your own, and include them from each .c file; this produces much the same result as you would get with autoconf and its generated config.h. However, it may unnecessarily include files slowing compilation down.

   实现这一点的一种方法是将您的所有系统包含在您自己的一个包含文件中，并从每个.c文件中包含它们;这产生的结果与autoconf及其生成的config.h产生的结果基本相同。但是，它可能不必要地包含减慢编译的文件。

4. Some say put includes of system headers above your own includes. Whilst this is often seen as good practice, it doesn't work great if your own .h files reference types defined in system includes, e.g. stdint.h defines int32_t. If you include that in your .h file alone, you are back to a potential problem with include order and whether or not you've got your #define _GNU_SOURCE in the right place.

   有人说把包含的系统头放在你自己的包含上面。虽然这通常被视为良好的实践，但如果您自己的.h文件引用类型在system include中定义，例如stdint，那么它就不能很好地工作。h定义int32_t。如果您将它单独包含在.h文件中，那么您就回到了包含顺序的潜在问题，以及您的#define _GNU_SOURCE是否在正确的位置。

5. Therefore my personal coding style is to have a config.h equivalent, which is included by all .h files and (for good measure) all .c files as the first include, which contains all the relevant system includes. It's not ideal for compile time, but that's what precompiled headers are for. I normally arrange system includes in alphabetical order, unless there is a reason not to.

   因此我的个人编码风格是配置。h等效，它包含在所有.h文件和(为了更好地衡量)第一个包含的所有.c文件中，其中包含所有相关的系统包含。它不适合编译时，但这就是预编译头的用途。我通常按字母顺序排列系统，除非有理由不这样做。

6. The alternative is to (carefully) do it by file, as @meagar suggests.

   另一种选择是(小心地)通过file来完成，正如@meagar所建议的那样。