best way to manage the headers..

[broli]

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.

 

[Kaz Kylheku]

So is it a good idea to have a single all.h file ?

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.

My code must be around 7000 lines.

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.

 

[Thad Smith]

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.

There are several approaches to handle this. What you have is a good
start, assuming that vector.h requires math.h and reader.h requires stdio.h
and stdlib.h (are you using size_t as a parameter type?).

If a module uses stdio.h, simply include it, even though it is also
included from 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.

I usually attempt to make code as modular as possible, so don't use an all.h.

 

[broli]

Thad Smith said :

There are several approaches to handle this. What you have is a good
start, assuming that vector.h requires math.h and reader.h requires stdio.h
and stdlib.h (are you using size_t as a parameter type?).

If a module uses stdio.h, simply include it, even though it is also
included from reader.h.

Wouldn't this approach cause redundancy ?

 

[santosh]

Thad Smith said :

Wouldn't this approach cause redundancy ?

No. Header guards will prevent multiple inclusions into a single
translation unit.

Almost all headers have something like:

#ifndef HEADER_H
#define HEADER_H 1
/* contents of header */
#endif

or some functional equivalent.

The first time this header is included in a translation unit, the
preprocessor would not have defined the symbol HEADER_H yet, so it will
define it now and include the headers contents. The next time you
include a header the symbol would be already defined so everthing
between #ifndef HEADER_H and the corresponding #endif is skipped.

 

[broli]

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 ?

 

[Joachim Schmitz]

broli said:


You should have thought of that before trolling the group. You'll be
in quite a few killfiles by now.

indeed...

 

[broli]

broli said:


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

thats great!

 

[Richard]

He entered mine this morning, so I won't be able to
offer him any help until at least May 1. (First offenders
get a one-month sentence; repeat offenders go into the
Forever File.)

That's very interesting Eric. I'm sure we're all very impressed to hear
how you punish perceived offenders.

 

[Kenny McCormack]

That's very interesting Eric. I'm sure we're all very impressed to hear
how you punish perceived offenders.

I'm certainly hanging on every word. Tune in next time for another
episode of... Eric's Killfile!

 

[Default User]

He entered mine this morning, so I won't be able to
offer him any help until at least May 1. (First offenders
get a one-month sentence; repeat offenders go into the
Forever File.)

Ah. All my plonks are permanent. The idjit made mine as well.




Brian

 

[Kenny McCormack]

Ah. All my plonks are permanent. The idjit made mine as well.

Be still, my heart!

 

[CBFalconer]

Terrific. Unfortunately due to your earlier trolling, you will
find most of the /real/ experts have killfiled you. I myself
have just done so too.

Well, obviously you still saw him. I didn't.

 

[Kenny McCormack]

Terrific. Unfortunately due to your earlier trolling, you will find most
of the /real/ experts have killfiled you. I myself have just done so too.

At last. Now, I can sleep at night.

 

[Richard]

Ah. All my plonks are permanent. The idjit made mine as well.




Brian

Really? Very interesting Brian. And this is topical to c.l.c how
exactly? if you were not you I'm sure you would be telling yourself off
now for posting "OT".