TIGSource Forums

hey,

i've started using c and it works fine so far, but my header work is a joke and i could use some help.
 
Just as an example(in a simple turn- and tilebased game):
 
i have the modules gamelogic, map and weapon. gamelogic needs map and weapon, map needs some functions from gamelogic, weapon some from map and gamelogic. So: includes everywhere.
Also i define some structs in gamelogic.h (that weapon and map need also). Which means i ended up putting the includes after the definition of the structs, which seems messy.

But i'm a bit worried to leave out includes because when i started out, i did just that and some function was called but the passed arguments were wrong, well just the last one.

Any... pointers?

Some code would be useful. Are you using forward declarations? Do you have code in your headers, or is it just declarations?

in the header i have struct definitions and function declarations that other modules might need, that's all; every module(.c, not 100% sure if module is the right word) gets its own header.

I guess what i'm asking is, is it actually something to worry/think about?

Ritchie/Kernighan have only one sentence for this: "in our small example we put everything in one header file, for a larger program more organization and more headers would be needed".

Before i post stupid amounts of code, what parts would you want to see?
Thanks.

It sounds like the problem isn't headers, but design. Why would map need game logic functions and so forth for instance?

Same thing with weapons, what is the map and game logic being used for here? Are you doing something like a line of sight check inside the weapon which would need map access, instead of just having game logic do this check before calling on weapon to fire? Are you managing bullets or something in the weapon module, when you could instead have the bullet returned to the logic class that then manages them?

Regardless of whether it's good design, you should just be able to forward declare stuff any time you've got a circular dependency, so if you're not doing that, there's your problem, and if you are doing that, then there's probably some bigger thing going wrong that's not evident from your description

I love to have everything organized in their logical include files, plus one Game.h that includes all other includes. All .c/.cpp files only include Game.h. This not just makes things easy, but it also allows the use of precompiled headers, which increases compile times a billion.

I agree with this approach, except I think precompiled headers decrease compile times a billion ;)

I've never been able to get any real speed difference either way!  I've also never been able to find resources on how to properly use them

In my setup, precompiled headers help when you don't do header changes frequently but your changes are mostly all contained in the .cpp files (which I think should be the case at one point in the project, when all framework design is done and you just need to fill the implementation).

As it stands, fully rebuilding Hyper Void with full optimization (the release exe) takes about 8 seconds. Recompiling (no linking) all the source code takes ~3 seconds.  This is on an Intel i5 3.30 GHz machine with 4 GB RAM. Windows 7 x64 and Visual Studio 2013. Generating the precompiled header usually takes ~2 seconds (includes all engine and Win32 header stuff), then all other .cpp files compile in a breeze once the PCH is ready


The setup is rather easy, is that what you're having trouble with?

Clang thinks that this is a task that the machine should do anyway.

Rules of thumb:
- One header per source file
- Header name = source file name
- Unless impossible, always forward-declare

I mean, I can stick headers in stdafx, and it all 'works', but either way my engine takes 40+ seconds to do a full compile, and that's after I've done a ton of work to bring it down.  I must be doing something wrong, but whatever it is, I'm missing it.  How many LOC do you have?

That's really not a long compile.  My release builds take at least 5 minutes.  When I worked on MS Office, it took about 6 hours.

You're probably fine right where you are.  Besides, how often do you do full builds?  Should be relatively rarely.

This is only the game code, not the engine nor the pipeline.

hmm i think you and zacaj are more or less right. Will have to restructure some things. With the headers i'm basically just forward declaring functions, so more or less just as if was copying the declarations into the *.c file by hand.


that sounds good, maybe i'll steal that. ;)

Thanks everyone.

This seems like an incredibly poor approach to me.  It makes every single one of your source files sensitive to changes in every header.

I bet you'd get better results by dumping the monolithic header and only including what you need in each source file.

Theoretically you can separate your declarations into as many headers as possible, then in the source file you only include the headers you need. For example, a header to declare Vector3, another to declare Matrix4x4...etc. This will lead to the best compile times for each .cpp file, but not the best for overall performance. This is because various headers will be recompiled over and over again for each .cpp file. It's also tedious to keep a long list of #includes on top of every .cpp.

Precompiled headers remove this redundancy. Depending on the size of your project, you might need multiple precompiled headers. E.g., one for all AI, one for Graphics...etc.I'm talking in the scale of ~40 files per area or more for this to be necessary. Otherwise you can get similar to the compile times I mentioned for my game with one monolithic header... and I think my compile times are quite acceptable.

A few things you should remember about headers in order to not make poor decisions, or pollute your file structure with headers:

• #include literally just inserts the file specified at that line. There's nothing special about the *.h files, it's just a convention.
  
• Most C compilers including GCC are single-pass, which is why pre-declaration is needed.
• You only really need one header (source file of pre-declarations) for a group of related *.c source files. Look at the Quake 3 Source to see how this is done, and how to leverage this for data hiding, etc.