温馨提示！由于新浪微博认证机制调整，您的新浪微博帐号绑定已过期，请重新绑定！&&|&&
LOFTER精选
网易考拉推荐
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
阅读(845)|
用微信&&“扫一扫”
将文章分享到朋友圈。
用易信&&“扫一扫”
将文章分享到朋友圈。
历史上的今天
loftPermalink:'',
id:'fks_',
blogTitle:'C语言中避免重复包含头文件',
blogAbstract:'&
#ifndef MONGOOSE_HEADER_INCLUDED#define&&& MONGOOSE_HEADER_INCLUDED
#ifdef __cplusplusextern \"C\" {#endif /* __cplusplus */
/*.................................&* do something here&*.................................&*/
#ifdef __cplusplus}#endif /* __cplusplus */
#endif /* MONGOOSE_HEADER_INCLUDED',
blogTag:'',
blogUrl:'blog/static/',
isPublished:1,
istop:false,
modifyTime:0,
publishTime:2,
permalink:'blog/static/',
commentCount:0,
mainCommentCount:0,
recommendCount:0,
bsrk:-100,
publisherId:0,
recomBlogHome:false,
currentRecomBlog:false,
attachmentsFileIds:[],
groupInfo:{},
friendstatus:'none',
followstatus:'unFollow',
pubSucc:'',
visitorProvince:'',
visitorCity:'',
visitorNewUser:false,
postAddInfo:{},
mset:'000',
remindgoodnightblog:false,
isBlackVisitor:false,
isShowYodaoAd:false,
hostIntro:'我叫N',
hmcon:'0',
selfRecomBlogCount:'0',
lofter_single:''
{list a as x}
{if x.moveFrom=='wap'}
{elseif x.moveFrom=='iphone'}
{elseif x.moveFrom=='android'}
{elseif x.moveFrom=='mobile'}
${a.selfIntro|escape}{if great260}${suplement}{/if}
{list a as x}
推荐过这篇日志的人：
{list a as x}
{if !!b&&b.length>0}
他们还推荐了：
{list b as y}
转载记录：
{list d as x}
{list a as x}
{list a as x}
{list a as x}
{list a as x}
{if x_index>4}{break}{/if}
${fn2(x.publishTime,'yyyy-MM-dd HH:mm:ss')}
{list a as x}
{if !!(blogDetail.preBlogPermalink)}
{if !!(blogDetail.nextBlogPermalink)}
{list a as x}
{if defined('newslist')&&newslist.length>0}
{list newslist as x}
{if x_index>7}{break}{/if}
{list a as x}
{var first_option =}
{list x.voteDetailList as voteToOption}
{if voteToOption==1}
{if first_option==false},{/if}&&“${b[voteToOption_index]}”&&
{if (x.role!="-1") },“我是${c[x.role]}”&&{/if}
&&&&&&&&${fn1(x.voteTime)}
{if x.userName==''}{/if}
网易公司版权所有&&
{list x.l as y}
{if defined('wl')}
{list wl as x}{/list}帐号:密码:下次自动登录{url:/nForum/slist.json?uid=guest&root=list-section}{url:/nForum/nlist.json?uid=guest&root=list-section}
贴数:6&分页:bye发信人: gnwd (xiang), 信区: CProgramming
标&&题: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Sat Feb&&6 13:04:01 2016), 站内 && 如果放源文件，头文件放typedef && 我看到两种做法都有
--来自微水木3.2.0
-- && ※ 来源:·水木社区 ·[FROM: 113.248.156.*]
NULL发信人: heracules (NULL), 信区: CProgramming
标&&题: Re: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Sat Feb&&6 14:06:14 2016), 站内 && 要是只有该文件会用到这个结构体，那就在源文件里定义&& &&&& 【 在 gnwd () 的大作中提到: 】
: 如果放源文件，头文件放typedef
: 我看到两种做法都有
: --来自微水木3.2.0
发自xsmth (iOS版)
-- && ※ 来源:·水木社区 ·[FROM: 117.136.38.*]
bye发信人: gnwd (xiang), 信区: CProgramming
标&&题: Re: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Sat Feb&&6 16:58:52 2016), 站内 && 嗯嗯
【 在 heracules 的大作中提到: 】
: 要是只有该文件会用到这个结构体，那就在源文件里定义&&
: 【 在 gnwd () 的大作中提到: 】
: ...................
--来自微水木3.2.0
-- && ※ 来源:·水木社区 ·[FROM: 113.248.156.*]
每天不许偷懒!!!发信人: flyoutsky (每天不许偷懒!!!), 信区: CProgramming
标&&题: Re: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Sun Feb&&7 08:50:32 2016), 站内 && 两种都有吧，看你想怎么定义这个结构体的api了吧
【 在 gnwd (xiang) 的大作中提到: 】
: 如果放源文件，头文件放typedef
: 我看到两种做法都有
: --来自微水木3.2.0
: ...................
&& -- && ※ 来源:·水木社区 newsmth.net·[FROM: 207.194.236.*]
bye发信人: gnwd (xiang), 信区: CProgramming
标&&题: Re: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Fri Feb 12 23:21:45 2016), 站内 && 这个我现在已经比较清楚了。最近模仿人家的写了一个list库
【 在 flyoutsky 的大作中提到: 】
: 两种都有吧，看你想怎么定义这个结构体的api了吧
: 【 在 gnwd (xiang) 的大作中提到: 】
: : 如果放源文件，头文件放typedef
: ...................
--来自微水木3.2.0
-- && ※ 来源:·水木社区 ·[FROM: 113.248.158.*]
fenqing发信人: fenqingp (fenqing), 信区: CProgramming
标&&题: Re: 结构体定义放在头文件还是源文件中呢？
发信站: 水木社区 (Sun Jun 19 11:59:13 2016), 站内 && 都可以，看自己需要
-- && ※ 来源:·水木社区 ·[FROM: 210.12.222.*]
文章数:6&分页:
抽奖到手软！将狂欢进行到底！http://blog.csdn.net/liangwei88624/article/details/6284661
& 在编译器只认识.c(.cpp))文件，而不知道.h是何物的年代,那时的人们写了很多的.c(.cpp)文件，渐渐地，人们发现在很多.c(.cpp)文件中的声明语句就是相同的，但他们却不得不一个字一个字地重复地将这些内容敲入每个.c(.cpp)文件。但更为恐怖的是，当其中一个声明有变更时，就需要检查所有的.c(.cpp)文件。
&&& 于是人们将重复的部分提取出来，放在一个新文件里,然后在需要的.c(.cpp)文件中敲入#include XXXX这样的语句。这样即使某个声明发生了变更，也再不需要到处寻找与修改了。因为这个新文件，经常被放在.c(.cpp)文件的头部，所以就给它起名叫做“头文件”，扩展名是.h。
&&& 在我们语言的初学阶段，往往我们的程序只有一个.c的文件或这很少的几个，这时我们就很少遇到头文件组织这个头疼的问题，随着我们程序的增加，代码 量到了几千行甚至几万行，文件数也越来越多。这时这些文件的组织就成了一个问题，其实说白了这些文件的组织问题从理论上来说是软件工程中的模块设计等等的问题。
&&& 头文件的作用的简短描述:
（1）通过头文件来调用库功能。在很多场合，源代码不便（或不准）向用户公布，只要向用户提供头文件和二进制的库即可。用户只需要按照头文件中的接口声明来调用库功能，而不必关心接口怎么实现的。编译器会从库中提取相应的代码。
（2）头文件能加强类型安全检查。如果某个接口被实现或被使用时，其方式与头文件中的声明不一致，编译器就会指出错误，这一简单的规则能大大减轻程序员调试、改错的负担。
&&& 比方说 我在aaa.h里定义了一个函数的声明，然后我在aaa.h的同一个目录下建立aaa.c ， aaa.c里定义了这个函数的实现，然后是在main函数所在.c文件里#include这个aaa.h& 然后我就可以使用这个函数了。 main在运行时就会找到这个定义了这个函数的aaa.c文件。这是因为：main函数为标准C/C++的程序入口，编译器会先找到该函数所在的文件。假定编译程序编译myproj.c（其中含main()）时，发现它include了mylib.h（其中声明了函数void test()），那么此时编译器将按照事先设定的路径（Include路径列表及代码文件所在的路径）查找与之同名的实现文件（扩展名为.cpp或.c，此例中为mylib.c），如果找到该文件，并在其中找到该函数（此例中为void
test()）的实现代码，则继续编译；如果在指定目录找不到实现文件，或者在该文件及后续的各include文件中未找到实现代码，则返回一个编译错误.其实include的过程完全可以“看成”是一个文件拼接的过程，将声明和实现分别写在头文件及C文件中，或者将二者同时写在头文件中，理论上没有本质的区别。
&&& 理论上来说C文件与头文件里的内容，只要是C语言所支持的，无论写什么都可以的，比如你在头文件中写函数体，只要在任何一个C文件包含此头文件就可以将这个函数编译成目标文件的一部分（编译是以C文件为单位的，如果不在任何C文件中包含此头文件的话，这段代码就形同虚设），你可以在C文件中进行函数声明，变量声明，结构体声明，这也不成问题！！！那为何一定要分成头文件与C文件呢？又为何一般都在头件中进行函数，变量声明，宏声明，结构体声明呢？而在C文件中去进行变量定义，函数实现呢？？
&& 要理解C文件与头文件有什么不同之处，首先需要弄明白编译器的工作过程，一般说来编译器会做以下几个过程：&
1.预处理阶段&
2.词法与语法分析阶段&
3.编译阶段，首先编译成纯汇编语句，再将之汇编成跟CPU相关的二进制码，生成各个目标文件&
4.连接阶段，将各个目标文件中的各段代码进行绝对地址定位，生成跟特定平台相关的可执行文件，编译器在编译时是以C文件为单位进行的，也就是说如果你的项目中一个C文件都没有，那么你的项目将无法编译，连接器是以目标文件为单位，它将一个或多个目标文件进行函数与变量的重定位，生成最终的可执行文件，在PC上的程序开发，一般都有一个main函数，这是各个编译器的约定。为了生成一个最终的可执行文件，就需要一些目标文件，也就是需要C文件，而这些C文件中又需要一个main函数作为可执行程序的入口。&
&&& 简单些说就是C语言的编译分为预处理、编译、汇编、链接（test.c test.h =& test.i =& test.s =& test.o =& test）四个大的阶段。c文件中的#include宏处理，会在预处理的阶段将c中引用的h文件的内容全部写到c文件中，最后生成.i中间文件，这时h 文件中的内容就相当于被写道c文件中。这也为代码的复用提供了渠道，很多的c文件可以去引用同一个h文件，这样这个h文件就会被放到多个c文件中被编译多 次，这也是h文件中不能放定义只能放声明的原因，放定义时被编译多次，在程序链接的时候（系统中定义了多个int
强符号定义)会出现错误， 声明就不一样，声明表示对定义的扩展，最终都会终结到一个定义上，所以不会出现link时重复定义的错误。
编程中我们在h文件中肯定都用过一下的格式
&span style=&color: rgb(51, 153, 51);&&#ifndef
XXX_H&/span&
&span style=&color: rgb(51, 153, 51);&&#define
XXX_H&/span&
&span style=& color: rgb(102, 102, 102);&&&em&//……&/em&&/span&
&span style=&color: rgb(51, 153, 51);&&#endif&/span&
呵呵，那他到底有什么用呢，在h文件互相引用时，消除重复定义。当然宏定义是在预处理阶段发挥作用的，编译方后的过程是没有宏的影子的。
A.&span style=&color: rgb(32, 32, 32);&&h&/span&
&span style=&color: rgb(153, 51, 51);&&int&/span& a&span style=&color: rgb(0, 153, 0);&&(&/span&&span style=&color: rgb(0, 153, 0);&&)&/span&;
B.&span style=&color: rgb(32, 32, 32);&&h&/span&
&span style=&color: rgb(51, 153, 51);&&#include &A.h&&/span&
C.&span style=&color: rgb(32, 32, 32);&&h&/span&
&span style=&color: rgb(51, 153, 51);&&#include &A.h&&/span&
D.&span style=&color: rgb(32, 32, 32);&&h&/span&
&span style=&color: rgb(51, 153, 51);&&#include &A.h&&/span&
&span style=&color: rgb(51, 153, 51);&&#include &B.h&&/span&
上面的D.h文件中就会重复出现两个int a();的声明阿，这样就有点重复了，这时条件编译宏就派上了用场
A.&span style=&color: rgb(32, 32, 32);&&h&/span&
&span style=&color: rgb(51, 153, 51);&&#ifndef A_H&/span&
&span style=&color: rgb(51, 153, 51);&&#define A_H&/span&
&span style=&color: rgb(153, 51, 51);&&int&/span& a&span style=&color: rgb(0, 153, 0);&&(&/span&&span style=&color: rgb(0, 153, 0);&&)&/span&;
&span style=&color: rgb(51, 153, 51);&&#endif&/span&
这样就不会重复定义了。
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：8111次
排名：千里之外
转载：53篇
(2)(2)(3)(43)(1)(2)编程（12）
在学习开源的LZ77-neoben时，看到有的结构体（如struct header）定义在对应头文件中，而结构体struct bitbuf定义在.c文件中。就不明白这是什么考虑了。因为感觉定义在头文件中很方便呀。
http://www.oschina.net/question/93?sort=default&p=1 & &
——如果其可见性超出一个.c文件，那么应当放入.h中，如果只是某个.c里需要这么一个结构作为辅助，直接放入这个.c中更好一些。 .h的影响范围更大，如果有修改的话所有依赖的文件都要重新编译，会影响编译效率，主要就是基于这个考虑
——放在.h里不是为了可读性更高。
你可能认为放在.c文件中，一看就可以看到，但是稍微好用点儿的编辑器，如：sourceinsight，vi等等，都可以做到跳转，很方便阅读。
假设你要和其他模块传递数据，你定义了一个结构体，然后放在common.h（假设有这个文件），别人在解析你传来的数据的时候，只需要在他的代码里#include &common.h&即可使用该结构体，试想一下，如果你放在.c文件中，别人该怎么办呢？难道#include 你的.c文件？太扯了吧。
综合来说，
1.全局变量一般都用static包裹，然后提供配套的set和get接口给别人调用，放在.c文件中。
2.结构体、枚举、宏（名字尽量复杂点，避免和别人的宏重复）、定义放在.h中，可以让别人include，提高代码的复用率。
这是我个人的理解，可能很多地方没说全，或者说错，请见谅。
——.h可以typedef struct foo *
.c里去实现这个结构体
主调用文件可以以类似函数接口的形式操作struct foo，这样结构体就可以保持在主调用文件中的可见性了&
可以看看&C Interfaces and Implementations这本书
——头文件中定义的是模块的接口（函数原型）。
对应的C文件中是对应模块的函数原型的实现。
如果某个结构体 会在 用这个模块的程序中出现。那需要定义在.h文件。（或者说，需要被模块外的程序访问）
如果某个结构题仅仅是在 函数原型实现中（对应的C文件中）才用到，那最好写在.c文件中。
——提供给别人的接口越隐藏细节，接口越简单，耦合越少，越容易修改。但是把结构体定义在.c文件使用的人就不能在栈上分配内存了。
——放c还是h取决于该结构是否要暴露给其他c,原则就是能放c绝不放h,但一般来说既然定义了结构,多半还是要暴露出来的.
参考知识库
* 以上用户言论只代表其个人观点，不代表CSDN网站的观点或立场
访问：45326次
积分：1668
积分：1668
排名：第18925名
原创：114篇
转载：76篇
(2)(4)(12)(14)(9)(11)(35)(14)(48)(2)(8)(2)(12)(5)(13)