#包括在.h或.c / .cpp中?

当用C或C ++编码时,我应该在哪里使用#include

callback.h:

 #ifndef _CALLBACK_H_ #define _CALLBACK_H_ #include <sndfile.h> #include "main.h" void on_button_apply_clicked(GtkButton* button, struct user_data_s* data); void on_button_cancel_clicked(GtkButton* button, struct user_data_s* data); #endif 

callback.c:

 #include <stdlib.h> #include <math.h> #include "config.h" #include "callback.h" #include "play.h" void on_button_apply_clicked(GtkButton* button, struct user_data_s* data) { gint page; page = gtk_notebook_get_current_page(GTK_NOTEBOOK(data->notebook)); ... 

应该都包含在.h或.c / .cpp中,还是像我在这里所做的一样?

尽可能多的放在.c ,尽可能less放在.h.c中的包含仅包含在编译一个文件时,但包含的.h必须包含在每个使用它的文件中。

只有在另一个.h文件中包含头文件的时候,你需要访问头文件中的types定义; 例如:

 #ifndef MY_HEADER_H #define MY_HEADER_H #include <stdio.h> void doStuffWith(FILE *f); // need the definition of FILE from stdio.h #endif 

如果标题A依赖于标题B(例如上面的示例),则标题A应该直接包含标题B. 不要试图在.c文件中命令你的包含来满足依赖关系(也就是说,在头部A之前包括头部B); 那是一大堆等待发生的胃灼热。 我是认真的。 我曾多次参加那部电影,它总是以东京在火焰中结束。

是的,这可能会导致文件被多次包含,但是如果他们有适当的包含警卫来防止多个声明/定义错误,那么额外几秒的构build时间是不值得担心的。 试图手动pipe理依赖关系是一个痛苦的屁股。

当然,你不应该包括你不需要的文件。

把尽可能多的包含在你的CPP中,只有hpp中hpp文件所需的那些包含在你的CPP中。 我相信这将有助于加快编译,因为hpp文件将交叉引用较less。

还要考虑在hpp文件中使用forward声明来进一步减lessinclude依赖链。

如果我#include <callback.h> ,我不想#include许多其他头文件来获得我的代码编译。 在callback.h你应该包含编译所需的所有东西。 但没有更多。

考虑在头文件中使用forward声明(比如class GtkButton; )是否足够,可以减less头文件中的#include指令的数量(进而减less编译时间和复杂度)。