在头文件中包含头文件,是不是一个非常坏的习惯?

昵称是神马 2014-03-04 12:45:29
在头文件中包含头文件,是不是一个非常坏的习惯?


自己写的头文件,然后又包含另一个头文件,当文件一多的时候,经常冒出一些莫名其妙的编译错误。。。
(比如语法错误:标示符吧啦吧啦)
这是一个很坏的习惯吧,是不是应该把所有包含头文件的界面都放到cpp中去呢?

还有标准库头文件是不是和普通我们自己写的头文件一样处理?
...全文
3149 25 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
25 条回复
切换为时间正序
请发表友善的回复…
发表回复
赵4老师 2014-03-13
  • 打赏
  • 举报
回复
打开stdio.h和stdlib.h看看人家里面包含别的头文件了没。
江北百晓生 2014-03-13
  • 打赏
  • 举报
回复
引用 21 楼 AgedBOY 的回复:
[quote=引用 18 楼 huxizero10 的回复:] 跨平台用
#ifndef FILENAME_H
#define FILENAME_H
//Code ..
#endif
VC可以用
#pragma once
Linux上的G++也可以用#pragma once,试之前我也以为不行来的。[/quote] Compiler #pragma once Clang 支持[4] Comeau C/C++ 支持[5] C++Builder XE3 支持[6] Digital Mars C++ 支持[7] GCC 支持[8] ( 3.4版本以后[9]) Intel C++ Compiler 支持[10] Microsoft Visual C++ 支持[11] Pelles C 支持[12] IAR C/C++ 支持[13]
江北百晓生 2014-03-13
  • 打赏
  • 举报
回复
引用 21 楼 AgedBOY 的回复:
[quote=引用 18 楼 huxizero10 的回复:] 跨平台用
#ifndef FILENAME_H
#define FILENAME_H
//Code ..
#endif
VC可以用
#pragma once
Linux上的G++也可以用#pragma once,试之前我也以为不行来的。[/quote] 老版本的GCC不支持这个。这个比较新吧
AgedBOY 2014-03-10
  • 打赏
  • 举报
回复
引用 18 楼 huxizero10 的回复:
跨平台用
#ifndef FILENAME_H
#define FILENAME_H
//Code ..
#endif
VC可以用
#pragma once
Linux上的G++也可以用#pragma once,试之前我也以为不行来的。
Morrisss_ 2014-03-09
  • 打赏
  • 举报
回复
用得到声明,用不到定义就可以用前向声明代替。
江北百晓生 2014-03-08
  • 打赏
  • 举报
回复
跨平台用
#ifndef FILENAME_H
#define FILENAME_H
//Code ..
#endif
VC可以用
#pragma once
lm_whales 2014-03-08
  • 打赏
  • 举报
回复
需要包含的,没有必要排除,同样不需要的也不要胡乱包含. 如果完全排除头文件的依赖关系, 还是需要依赖头文件的包含顺序,来使用头文件,也没有好大哪里去.
Falleyes 2014-03-06
  • 打赏
  • 举报
回复
对头文件进行包含,然后扩充接口不算坏习惯。在《C++编程思想》中可以看到这类代码。
哈利_蜘蛛侠 2014-03-05
  • 打赏
  • 举报
回复
引用 12 楼 lncn 的回复:
是的,随着代码量的增大,这样做的确容易出现问题, 尤其是有多个人同时进行开发的时候,你很难保证每个人对头文件的依赖都有一个清晰的认识。 1楼所说的可以解决重复包含,但应该不是楼主所说的问题。 实际上,这取决于你的代码的物理设计,即你的代码在文件中的分布。 理论上,如果你的每个头文件设计得足够的内聚,无论如何嵌套包含都不会出现问题。但是,这只是存在于理论上,实际的项目中做到比较因难。 因此,一个合理的建议:所有的.h中不包含.h,放在CPP中包含。但是每个模块有一个特殊的共通头文件,只用于包含该模块使用的外部的头文件,并且所有的cpp文件必须是最先包含该头文件。模块对外提供与内部使用的文件分目录存放。 这样做可以强制你清晰化模块之间的依赖关系(模块的共通头文件中的文件包含顺序就是你的模块依赖的顺序)。 如果把每组.h/.cpp文件看成一个小模块,你可以清晰的看出这些小模块之间的依赖顺序。
感觉好抽象啊,能举几个简单例子吗?
lncn 2014-03-05
  • 打赏
  • 举报
回复 1
是的,随着代码量的增大,这样做的确容易出现问题, 尤其是有多个人同时进行开发的时候,你很难保证每个人对头文件的依赖都有一个清晰的认识。 1楼所说的可以解决重复包含,但应该不是楼主所说的问题。 实际上,这取决于你的代码的物理设计,即你的代码在文件中的分布。 理论上,如果你的每个头文件设计得足够的内聚,无论如何嵌套包含都不会出现问题。但是,这只是存在于理论上,实际的项目中做到比较因难。 因此,一个合理的建议:所有的.h中不包含.h,放在CPP中包含。但是每个模块有一个特殊的共通头文件,只用于包含该模块使用的外部的头文件,并且所有的cpp文件必须是最先包含该头文件。模块对外提供与内部使用的文件分目录存放。 这样做可以强制你清晰化模块之间的依赖关系(模块的共通头文件中的文件包含顺序就是你的模块依赖的顺序)。 如果把每组.h/.cpp文件看成一个小模块,你可以清晰的看出这些小模块之间的依赖顺序。
dahaiI0 2014-03-05
  • 打赏
  • 举报
回复
主要是防止编译依赖吧,有可能只改动一个头文件,结果整个工程全部编译一遍,太造孽了
ztenv 版主 2014-03-05
  • 打赏
  • 举报
回复
需要时再包含,不需要的时候不包含,BS将所有头文件都包含到一个头文件中的做法,
luotuo44 2014-03-05
  • 打赏
  • 举报
回复
优先选择前向引用,而不是包含头文件。如果没办法前向引用,才是包含头文件。
libaoxin18 2014-03-05
  • 打赏
  • 举报
回复
利用头文件才能很好的解决对公用的相关头文件的共享,可以说实现继承吧。
哈利_蜘蛛侠 2014-03-05
  • 打赏
  • 举报
回复
1楼的方法是标准方法。
翅膀又硬了 2014-03-05
  • 打赏
  • 举报
回复
(1)尽量在cpp文件里面包含头文件 (2)可以把一些公用的结构或者类,写到一个头文件里。比如整个系统的各种数据结构体。
lm_whales 2014-03-05
  • 打赏
  • 举报
回复
引用 12 楼 lncn 的回复:
是的,随着代码量的增大,这样做的确容易出现问题, 尤其是有多个人同时进行开发的时候,你很难保证每个人对头文件的依赖都有一个清晰的认识。 1楼所说的可以解决重复包含,但应该不是楼主所说的问题。 实际上,这取决于你的代码的物理设计,即你的代码在文件中的分布。 理论上,如果你的每个头文件设计得足够的内聚,无论如何嵌套包含都不会出现问题。但是,这只是存在于理论上,实际的项目中做到比较因难。 因此,一个合理的建议:所有的.h中不包含.h,放在CPP中包含。但是每个模块有一个特殊的共通头文件,只用于包含该模块使用的外部的头文件,并且所有的cpp文件必须是最先包含该头文件。模块对外提供与内部使用的文件分目录存放。 这样做可以强制你清晰化模块之间的依赖关系(模块的共通头文件中的文件包含顺序就是你的模块依赖的顺序)。 如果把每组.h/.cpp文件看成一个小模块,你可以清晰的看出这些小模块之间的依赖顺序。
++
图灵狗 2014-03-04
  • 打赏
  • 举报
回复
很正常的用法,头文件用 #ifndef __XXX_H__ #define __XXX_H__ ... #endif 限定就好了。
引用 楼主 yujiefei0309 的回复:
在头文件中包含头文件,是不是一个非常坏的习惯? 自己写的头文件,然后又包含另一个头文件,当文件一多的时候,经常冒出一些莫名其妙的编译错误。。。 (比如语法错误:标示符吧啦吧啦) 这是一个很坏的习惯吧,是不是应该把所有包含头文件的界面都放到cpp中去呢? 还有标准库头文件是不是和普通我们自己写的头文件一样处理?
百曉生 2014-03-04
  • 打赏
  • 举报
回复
我不懂这个,占个位置,学习
百曉生 2014-03-04
  • 打赏
  • 举报
回复
引用 5 楼 u010165006 的回复:
[quote=引用 4 楼 truelance 的回复:] 1. 头文件应该自包含,也就是说头文件中使用了的定义,需要在将定义所在的头文件包含进来。而没有在本头文件中使用,是在cpp文件中使用的定义,不应该在头文件中包含。 2. 如1楼的方式防止重复包含
学习了[/quote] +1, lz说的这个还真是不清楚
加载更多回复(4)

65,185

社区成员

发帖
与我相关
我的任务
社区描述
C++ 语言相关问题讨论,技术干货分享,前沿动态等
c++ 技术论坛(原bbs)
社区管理员
  • C++ 语言社区
  • encoderlee
  • paschen
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
  1. 请不要发布与C++技术无关的贴子
  2. 请不要发布与技术无关的招聘、广告的帖子
  3. 请尽可能的描述清楚你的问题,如果涉及到代码请尽可能的格式化一下

试试用AI创作助手写篇文章吧