请大家说说 结构体 是放在头文件中好? 还是放在源文件好呢?

mew 2011-11-21 09:03:52
在昨天, 我在网上看了一下关于C语言的模块化设计的一些文章,
现在, 就想问各位 你们的结构体的申明放在什么地方好, 好在什么地方,

我先来说说, 在头文件中放置 结构体的定义有什么缺点.

1. 在头文件放结构体的话, 会把整个结构体信息放在头文件中, 会把整个结构的信息暴露出来.这样不利于模块化.

呵呵, 不会吧,怎么我就说出了一点缺点..

如果放在源文件中, 这个缺点给补上了.
对这个结构体的使用, 可以完全的通过结构体所在模块提供一定的函数来操作....

但是我这样做遇到了一点问题, 不知道该怎么处理

下面是一个有问题的例子.



//filename :temp_main.c

#include "./temp.h"

int main(void ) {
struct temp a = creat_temp("wangxinglong", 12);
display(a);
return 1;
}



//filename: temp.c

#include <stdio.h>
#include "./temp.h"


struct temp {
char name[255];
int id;
};


int creat_temp(char *name, int id)
{
struct temp z;
sprintf(z.name, "%s", name);
z.id = id;
return 1;
}


int display(struct temp a)
{
printf("My name is: %s\n My id is: %d\n", a.name, a.id);
return 1;
}






//filename temp.h

#ifndef TEMP_H
#define TEMP_H

struct temp;

int creat_temp(char *name, int id);
int display(struct temp a);

#endif


这个问题是在编译, 根本就通过不了, 请各位支支招.
...全文
8820 43 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
43 条回复
切换为时间正序
请发表友善的回复…
发表回复
小小程序师 2012-12-20
  • 打赏
  • 举报
回复
当然是放在头文件中定义的嘛,这样子别的.c文件就可以使用了,而如果是放在.c文件中,那么其他的.c文件就不可用了。楼上有很多人都给出了很好的解释……顶……
氓流军军 2012-03-31
  • 打赏
  • 举报
回复
ForestDB同学给出了正解。
内核里可以看到这种处理方式,例如workqueue_struct.
Soulic 2011-11-25
  • 打赏
  • 举报
回复
LZ,我编不过就对了,

定义 int creat_temp(char *name, int id);
调用 struct temp a = creat_temp("wangxinglong", 12);

怎么可能编过
LingeCoding 2011-11-24
  • 打赏
  • 举报
回复
建议楼主学习一下,印第安山的编码标准

如果一个结构体,要被其他模块调用,那么应该放到头文件中
如果一个结构体私有,那么最好放到代码文件中,并加上static隐藏起来
鲲尘千古 2011-11-24
  • 打赏
  • 举报
回复
头文件啊,你就把结构体想成是类,你想向C++里面的类释放在哪儿的
赵4老师 2011-11-24
  • 打赏
  • 举报
回复
好的代码结构+不好用的代码编辑器≈不好的代码结构+好用的代码编辑器
贪食蛇男 2011-11-22
  • 打赏
  • 举报
回复
这就好比如果外部要使用你的类的一个成员,你就把把这个成员设置成 public 一样(friend就不说了)。
放头文件相当于 public ,放源文件相当于 private
贪食蛇男 2011-11-22
  • 打赏
  • 举报
回复 1
很简单,如果想提供给其他模块,就在头文件中定义,如果只是一个单独的CPP文件中用到,基于封装原则,定义在CPP文件里为好。
这和以下原则类似:
1. 类的成员能 private 就 private
2. 函数能 static 就 static

虽然这些对于程序的编译执行结果没甚影响,但维护时可以一眼看出来这些东西不会在别的地方被引用到,缩短调试耗时。
小笨同学 2011-11-22
  • 打赏
  • 举报
回复
不懂LZ的“暴露”是什么意思,如果知道了类型的内部细节可以做些什么,顶多用这个类型定义一个新变量,注意把类型和变量、函数区分开来,头文件中一般都包含宏、类型的定义、函数原型等,注意区分结构体类型的定义和结构体变量的声明。
ForestDB 2011-11-22
  • 打赏
  • 举报
回复
至于LZ提到的文章,感觉像用低级语言来“封装”高级语言的效果,比如namespace,比如类。
对于这样的行为,个人的观点是什么语言做什么事,其他意义不是特别大,对每种语言来说,都有它特定的实践。虽然没有限制用汇编做企业应用,用Java来做驱动,但是,你懂的。
ForestDB 2011-11-22
  • 打赏
  • 举报
回复

//filename temp.h

#ifndef TEMP_H
#define TEMP_H

struct temp; // <-- 这里是个不完整定义
int creat_temp(char *name, int id);
int display(struct temp a); // <-- 这里只能用strcut temp * a这样的东西
#endif


建议先多看看开源的代码,看看别人是怎样组织工程的,再回过头来看什么好。
fight_to_win_1980 2011-11-22
  • 打赏
  • 举报
回复
结构体当然放在头文件中,大型软件都是封库,放在哪里都很安全,放在头文件好处多多,如果别的.C要用,include一下就可,如果放在.C里面 ,这就比较悲剧了。
ynwenta 2011-11-22
  • 打赏
  • 举报
回复
如果是已经标准化的.h,请你不要放到里面(维护原有的准确性和严谨性吧,那怕有瑕疵但确确实实是经过很多人讨论过,研究过的!);如果是作者本人定义的.h或者源文件,那就看作者本人的习惯和使用方便吧!
柯本 2011-11-22
  • 打赏
  • 举报
回复
[Quote=引用 7 楼 qq120848369 的回复:]
多个文件都用同一个结构体就放头文件里。

如果只有一个源文件用,那就直接写在那个源文件里。
[/Quote]
++
如果你的结构体是一个接口,那你必须放在头文件中
模块化设计时接口很重要,你不可能在每个模块中重写一编结构的声明,那样就无法维护程序了(试想下,一个大的工程有N多人开发,有N多文件要用同一结构,当结构要修改时,不可能让每个人都改一遍吧)
孤飞俊驰 2011-11-22
  • 打赏
  • 举报
回复
支持7楼的,如果就一个文件用到结构体,放在源文件里就行了,如果多个源文件要用到这结构体,就放在头文件里。
无名剑 2011-11-22
  • 打赏
  • 举报
回复
这个是看需求而定吧,有一些结构不需要外部知道 只想内部使用可以放到cpp,这样外部无法使用你这个结构体.这样的设计是让外部调用你这个模块的时候不需要关注太多细节,对你的要求则是你所给予的接口足够外部在不清楚这个结构的时候调用.其实代码结构还是设计得简单点好,我们代码的目的就是让别人用,让代码接口清晰,外部使用简单就能够达到想要功能.我是比较反对那种把程序分成无数个所谓的层,结果层来层去最后连自己都不知道这个程序到底在写什么.要分层,分结构,先看看这些是否是必须的,什么是可以改进的
rendao0563 2011-11-22
  • 打赏
  • 举报
回复
假如你看过一些常规的开源代码 应该知道的. 这属于非常常用的手法. 你上面那篇文章是对的. 自己好好体会.
hzy694358 2011-11-22
  • 打赏
  • 举报
回复
[Quote=引用 14 楼 xxyxxb 的回复:]

不懂LZ的“暴露”是什么意思,如果知道了类型的内部细节可以做些什么,顶多用这个类型定义一个新变量,注意把类型和变量、函数区分开来,头文件中一般都包含宏、类型的定义、函数原型等,注意区分结构体类型的定义和结构体变量的声明。
[/Quote]
同问,
放头文件会暴露,放源文件不会暴露??
如果其他文件要使用的话,就放头文件,你放源文件,莫非想让其他文件Include “***.cpp”
FrankHB1989 2011-11-22
  • 打赏
  • 举报
回复
[Quote=引用 15 楼 hiroyukki 的回复:]

很简单,如果想提供给其他模块,就在头文件中定义,如果只是一个单独的CPP文件中用到,基于封装原则,定义在CPP文件里为好。
这和以下原则类似:
1. 类的成员能 private 就 private
2. 函数能 static 就 static

虽然这些对于程序的编译执行结果没甚影响,但维护时可以一眼看出来这些东西不会在别的地方被引用到,缩短调试耗时。
[/Quote]
1和2略有区别。
先说后者。对于可以static的函数不去static,几乎纯粹是性能上的浪费——因为就算有需要要改成非static也不会费多少事(相比前者而言)。
但访问权限控制不同。首先,这里的语义不是运行时检查的,所以“不需要修改”就是最合适的的概率比较小。而private要修改成protected/public的风险是相当大的,在重构中不太容易修改(即使每次通读代码也完全无法保证这次修改后不会对之后的维护产生误导;相比之下,public改成private之类如果有问题一编译就检查出来了)。预先在并非逻辑上要求必须private的地方用private,变相拒绝代码在之后版本的修订,这其实也是很浪费的。至于“一眼看出来这些东西不会在别的地方被引用到”,还不如直接写文档清楚。


AnYidan 2011-11-22
  • 打赏
  • 举报
回复
具体问题具体分析、实现
加载更多回复(20)

70,019

社区成员

发帖
与我相关
我的任务
社区描述
C语言相关问题讨论
社区管理员
  • C语言
  • 花神庙码农
  • 架构师李肯
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

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