请大家说说 结构体 是放在头文件中好? 还是放在源文件好呢?
在昨天, 我在网上看了一下关于Ｃ语言的模块化设计的一些文章,
现在, 就想问各位 你们的结构体的申明放在什么地方好, 好在什么地方,
我先来说说, 在头文件中放置 结构体的定义有什么缺点.
１. 在头文件放结构体的话, 会把整个结构体信息放在头文件中, 会把整个结构的信息暴露出来.这样不利于模块化.
呵呵, 不会吧,怎么我就说出了一点缺点..
如果放在源文件中, 这个缺点给补上了.
对这个结构体的使用, 可以完全的通过结构体所在模块提供一定的函数来操作....
但是我这样做遇到了一点问题, 不知道该怎么处理
下面是一个有问题的例子.
//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
#defineTEMP_H
struct temp;
int creat_temp(char *name, int id);
int display(struct temp a);
#endif
这个问题是在编译, 根本就通过不了, 请各位支支招.
[解决办法]
我觉得模块化更多的应该是一种编程习惯。在使用结构体的时候强制自己不要直接去操纵结构体的内部变量，而是通过定义一组宏或者函数来操纵内部成员。只要你坚持这种用法，结构化就体现出来了。这也有助于提高移植性。
对于多个源文件都要用到的结构体，必须要在头文件中定义(如果编译器都不知道这个结构体占多大空间，它怎么能给你把源文件编译出来？)。而对于只在一个源文件中使用的结构体，可以选择在源文件或者头文件中定义，但我觉得还是放在头文件中好，事实上你可以单独为它建立个头文件，而如果你不用这个结构体，你就不应该包含这个头文件。从项目管理的角度看，一个结构体相当于对现实世界某种事物的抽象，在做一个项目的时候，通常是采用分层设计，先规划好，设计好数据结构以及函数接口（.h文件）,之后是去实现这些函数(.c文件)，最后是应用层函数。
最近在看linux源代码，里面很多结构体都是在头文件中定义的。
[解决办法]
很简单，如果想提供给其他模块，就在头文件中定义，如果只是一个单独的CPP文件中用到，基于封装原则，定义在CPP文件里为好。
这和以下原则类似：
1. 类的成员能 private 就 private
2. 函数能 static 就 static
虽然这些对于程序的编译执行结果没甚影响，但维护时可以一眼看出来这些东西不会在别的地方被引用到，缩短调试耗时。
[解决办法]
1和2略有区别。
先说后者。对于可以static的函数不去static，几乎纯粹是性能上的浪费——因为就算有需要要改成非static也不会费多少事（相比前者而言）。
但访问权限控制不同。首先，这里的语义不是运行时检查的，所以“不需要修改”就是最合适的的概率比较小。而private要修改成protected/public的风险是相当大的，在重构中不太容易修改（即使每次通读代码也完全无法保证这次修改后不会对之后的维护产生误导；相比之下，public改成private之类如果有问题一编译就检查出来了）。预先在并非逻辑上要求必须private的地方用private，变相拒绝代码在之后版本的修订，这其实也是很浪费的。至于“一眼看出来这些东西不会在别的地方被引用到”，还不如直接写文档清楚。
[解决办法]
假如你看过一些常规的开源代码 应该知道的. 这属于非常常用的手法. 你上面那篇文章是对的. 自己好好体会.