管理标题的最佳方法.. [英] best way to manage the headers..
问题描述
在我的项目中，处理所有
标题变得非常麻烦。例如。现在我的项目中有以下模块 -
vector.c
vector.h
test.c
reader.h
reader.c
vector.h
#ifndef VECTOR_H
#define VECTOR_H
#include< math.h>
.....
......
vector.c
#include" vector.h"
........................
reader.h
#ifndef READER_H
#define READER_H
#include< stdio.h>
#include< stdlib.h> ;
..........................
....... ....................
然后，我有test.c，需要reader.h，vector.h。但是，我可能需要包含stdio.h和stdlib.h而不是
其他的reader.h内容。另外，管理所有文件变得非常混乱了
。那么拥有一个all.h
文件是个好主意吗？我的代码必须大约7000行。
In my project it is getting really messy to take care of all the
headers..for eg. right now I have following modules in my project -
vector.c
vector.h
test.c
reader.h
reader.c
vector.h
#ifndef VECTOR_H
#define VECTOR_H
#include <math.h>
.....
......
vector.c
#include "vector.h"
........................
reader.h
#ifndef READER_H
#define READER_H
#include <stdio.h>
#include <stdlib.h>
..........................
...........................
And then, I have test.c which needs reader.h, vector.h. But there can
be instances where I may need to include stdio.h and stdlib.h but not
other contents of reader.h. also, it is getting extremely confusing
to manage all the files. So is it a good idea to have a single all.h
file ? My code must be around 7000 lines.
推荐答案
3月28日，9：23 * am，broli< Brol ... @ gmail.comwrote ：
On Mar 28, 9:23*am, broli <Brol...@gmail.comwrote:
所以有一个all.h文件是个好主意吗？
So is it a good idea to have a single all.h file ?
不，因为通过单个头文件进行多路复用，你将依赖图形折叠起来，然后每个.c文件依赖于每个.h
档。
现在任何时候触摸任何标题，你必须重新编译整个
程序。
如果你有一个all.h标题，你可能会取消一个基于
依赖的构建系统，并且（例如在Unix上）每次都会发生变化时构建这样的
程序： />
cc -o program * .c
另一个问题是重新编译每个.c文件有点慢
现在因为它们包含了更多无关的材料
这个all.h.
如果每个.c文件都包含每个标题，那么
的编译时间程序随着它的大小而呈二次方式增长！
的标题越多，每个.c文件中包含的材料就越多。
第三个问题是，如果你想翻译代码这个
程序，你遇到的问题是代码只包含
" all.h"。但是你不想拖动all.h。以及那段小的代码。
代码。所以你必须通过all.h确定究竟它取决于
，并且只采用那些标题，当然编辑
代码只包括那些标题。
换句话说，这种愚蠢的做法会干扰某些形式
的代码重用。
No, because by multiplexing through a single header, you fold together
the dependency graph, so that then every .c file depends on every .h
file.
Now any time you touch any header, you have to recompile the entire
program.
If you have an "all.h" header, you might as well do away with a
dependency based build system and (for example on Unix) build your
program like this, every time something changes:
cc -o program *.c
Another issue is that recompiling each of the .c files is a bit slower
now because they are including a lot more extraneous material by way
of this all.h.
If every .c file includes every header, than the compilation time for
the program grows quadratically with its size! The more headers there
are, the more material is included into each .c file.
A third issue is that if you ever want to rip code out of this
program, you run into the problem that the code simply includes
"all.h". But you don''t want to drag "all.h" along with that small
piece of code. So you have to figure out exactly what it depends on
through "all.h", and take only those headers, and of course edit the
code to include just those headers.
So in other words, this boneheaded practice interferes with some forms
of code reuse.
我的代码必须大约7000行。
My code must be around 7000 lines.
这没什么。对于这么小的程序来说，管理它是如何管理的并不重要。但是，如果它变成了一个alrger程序，或者你想要从它上面取出它并在其他地方使用它，那么
有一些程序在其中只有一个源文件是7000行。
That''s nothing. For such a small program, it doesn''t matter how it''s
managed. However, if it ever grows into a alrger program, or you want
to take pieces out of it and use it elsewhere,
There are programs in which just one source file is 7000 lines long.
在我的程序中，我确实有一种情况我需要制作
一切（几乎每个人都可以看到。
这就是我考虑all.h方法的原因。我的项目是基于光线追踪的
。你有模块 -
1. Ray（基本数据结构，光线初始化，
反射光线，阴影光线等）
2.几何文件阅读器（将几何体读入我的数据结构）
3.八叉树（用于3D对象的空间细分）
4.矢量模块（矢量数据结构，基本矢量函数）。
5.光线跟踪模块（跟踪光线）
6.雷 - 三角交叉模块
正如您所看到的，它们或多或少都相互依赖。我看到soemwhere的一个
方法是定义一个main.h文件。
项目中有很多文件 -
啊
ac
bh
bc
ch
cc
dh
dc
application.h
main.c
main.h
在这里，application.h包含了一些常见的#defines，prototypes
函数在main.c中，它包括标准头文件，如stdio，
math，string等。
main.h就像这个 -
#ifndef a_h
#include" a.h"
#endif
#ifndef b_h
#include" b.h"
#endif
#ifndef c_h
#include" c.h"
#endif
#ifndef d_h
#include" d.h"
#endif
#ifndef application_h
#include" application.h"
#endif
然后这个main.h包含在每个.c和.h文件中......
我以为这个也是一个很好的方法
你怎么看？
well in my program, i do have a situation where i need to make
everything(almost) visible to everyone.
which is why i was considering the all.h approach. My project is based
on ray tracing. You have module like -
1. Ray ( Basic Data structure , initialization of rays, creation of
reflected rays, shadow rays etc)
2. Geometry File Reader ( Reads the geometry into my data structures)
3. Octree ( For spatial subdivision of the 3D object)
4. Vector module ( Vector data structure, basic vector functions.)
5. Ray Tracing Module (To keep track of rays)
6. Ray - Triangle Intersection Module
As you can see they are all more or less dependent on each other. One
approach that I saw soemwhere was to define a main.h file.
There were many files in the project -
a.h
a.c
b.h
b.c
c.h
c.c
d.h
d.c
application.h
main.c
main.h
In this, application.h was containing some common #defines, prototypes
of functions in main.c and it included standard headers like stdio,
math, string etc.
main.h was like this -
#ifndef a_h
#include "a.h"
#endif
#ifndef b_h
#include "b.h"
#endif
#ifndef c_h
#include "c.h"
#endif
#ifndef d_h
#include "d.h"
#endif
#ifndef application_h
#include "application.h"
#endif
Then this main.h was included in every .c and .h file...
I thought this was also a neat approach
What do you think ?
broli说：
broli said:
在我的程序中，我确实有一种情况我需要制作
所有人（几乎）都能看到。
well in my program, i do have a situation where i need to make
everything(almost) visible to everyone.
在拖钓小组之前你应该想到这一点。你现在将在
相当多的杀戮文件。
-
Richard Heathfield< http：/ /www.cpax.org.uk>
电子邮件：-http：// www。 + rjh @
谷歌用户：< http://www.cpax.org.uk/prg/writings/googly.php>
Usenet是一个奇怪的放置" - dmr 1999年7月29日
You should have thought of that before trolling the group. You''ll be in
quite a few killfiles by now.
--
Richard Heathfield <http://www.cpax.org.uk>
Email: -http://www. +rjh@
Google users: <http://www.cpax.org.uk/prg/writings/googly.php>
"Usenet is a strange place" - dmr 29 July 1999
这篇关于管理标题的最佳方法..的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
