.c文件何时应该没有关联的.h文件?

这有一些用例。最明显的是主程序很少需要头文件。

第二个是你 不要 每个C文件有一个头。我以前把库放在一起(为了回答这个问题,让我们说一个BTree库),每个函数都在自己的源文件中,但是有一个库范围的头文件,类似于:

btree.h
btree_priv.h
btreeInit.c
btreeDestroy.c
btreeConfig.c

等等。私有头文件用于需要在代码之间共享但不在API中发布的内容。

最明显的是 .c 是完全独立的,不需要原型或外部的 .c.公司 文件夹。这基本上只适用于非常小的程序,或者那些通过def文件导出到插件到预定义接口的程序。

我见过大量的代码库 .h 文件定义了某个组件的接口,以及 .c 文件实现它。出于可维护性的原因,实现被分成几个文件,并在某些逻辑界限上进行了尝试。

有人可能会说,这样的逻辑界限可以应用于将组件划分为子组件,并因此具有多个头文件,但设计决策很少是黑白事件,有时这种方法确实有意义。

诚然,这种情况很少见,但也有可能发生。例如,我在嵌入式设备中完成了这项工作,用引导图形填充视频帧缓冲区。

如果将程序划分为多个模块,通常会有一个“main”模块,其中包含main()函数和其他一些东西。如果这个模块没有任何应该被另一个模块调用或使用的东西,则不需要在.h文件中导出接口。

我认为在.c和.h文件之间期望1对1的映射是一个糟糕的开始假设。扔掉它重新开始。:天

我建议如下,其中术语“代码模块”是一个或多个相关.c文件的组(通常是一个目录):

1. 为必须对其他代码模块可用的公共接口/定义创建头。
2. 为必须在代码模块内共享但不能与其他代码模块共享的私有接口/定义创建头。

这些是你唯一需要的头文件。如果这两个都不是必需的,则不需要标题。

有些程序员喜欢人为地将prototype/macros/typedefs/etc与.c中的globals/functions分离成一个.h。我建议不要使用这种方法,并建议在一个文件中包含所有相关的功能。然后根据需要移动到头,这些是绝对必要的,以防止在其他.c文件中出现“extern”。

如果您不需要 .h 文件,但实际上从来没有。

当一个文件包含多个程序生成的文件或包含需要编译多次的文件时(例如,我的一个项目有两个马达,它们的代码相同,只是它们使用不同的I/O端口和不同的变量;我的motor.c文件包含:

#define LOCK L0
#include "motor.i"
#undef LOCK
#define LOCK L1
#include "motor.i"
#under LOCK

请注意,在这个特定的嵌入式编译器上->运算符效率非常低,因此如下语句:

  L0.speed++;

  L0->speed++;

如果“速度”是结构中的第一项,则将转换为五条指令;如果“速度”占据任何其他位置,则将转换为七条指令。因此,用固定的可解析地址复制代码比用一个例程处理两个马达要快得多,而且节省空间。

如果有一个额外的文件与一个.c文件相关联,并且它包含真正的代码,我将其命名为“.I”。但不知道如果不止一个该怎么办。