Sign in to follow this  

Organizing header files

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Recommended Posts

How do you organize header files? If you have a complex file hierarchy like this:
/project
  /graphics
    /particlesystem
    /terrain
  /physics
    /collision
    /water
    /ragdoll
managing paths in #includes can get quite annoying. I'd rather write
#include "terrain.h"
than
#include "graphics/terrain/terrain.h"
One obvious solution is to run a script at the beginning of every compilation that grabs all header files and puts it under /project/includes. The problem with this is that when there are errors in the header files, the IDEs bring up a file from /project/includes when you try to look at the error. You end up modifying a temporary file that gets overwritten the next time you compile which is obviously a large pain in the ass. How do you handle this situation?

Share this post


Link to post
Share on other sites
Quote:
Original post by Maega
You can set additional include directories in your project so directory structure won't matter to the compiler.


To make this easier to manage, it's also a good idea to put the most common headers in a single include directory or in a single static library called CoreLib or something like that.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Well, adding many compiler directories also isn't a very good solution...

Does GCC support precompiled headers?


And writing a batch file is? :/


GCC should support precompiled headers.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Well, adding many compiler directories also isn't a very good solution...

Some IDEs+compilers like CodeWarrior automatically do this. Which is inappropriate, IMO.

I ran into problems where I had files with the same name in different project subdirectories: 2 "common.h" files. CodeWarrior was always including the wrong one because it searches the project paths in a certain order, and includes the one that comes first.

So generally, I agree with this point

Quote:
Does GCC support precompiled headers?

As far as I know, yes. You'll definitely find more details on the gcc website.

Quote:
How do you handle this situation?

I usually use relative pathing, e.g. "graphics/terrain/terrain.h"
It's not that bad - it forces you to think your directory structure before doing anything, which is good for things like CVS anyway.

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Took me 15 minutes after Olusei (damn, his name is hard to spell) recommended Python.

Not really that hard. Just stop for a minute, learn the pronounciation of his name by heart, and then you'll be able to write it in a sec: Oluseyi.

I tried to learn the spelling first, but that led me to nowhere [smile]

Share this post


Link to post
Share on other sites
I don't see what is so annoying about putting the paths in the #include. What is there to manage?

It helps if the organization of folders in a project mirrors the organization of the software. The source file and its header file should be kept together. Splitting them into separate folders seems like a very bad idea.

Keep the number of folders in the include path to a minimum. On a large project, you easily have more than 100 folders. Putting all those folders into the include path is going to cause problems.

Share this post


Link to post
Share on other sites
Quote:
Original post by Coder
Just stop for a minute, learn the pronounciation of his name by heart, and then you'll be able to write it in a sec: Oluseyi.

I can't even begin to imagine how his name is pronounced [smile]

Share this post


Link to post
Share on other sites
Quote:
Original post by JohnBolton
I don't see what is so annoying about putting the paths in the #include. What is there to manage?

Well, I have a somewhat deep hierarchy. For instance, with the path at the root of my project I get this for platform dependent files: arch/os/win32/window/window.h. It's really convinient to have my project organized like that but it's pretty annoying to have to write out this path in my #includes [smile]

I guess I'll just stick to using full path in the #includes. After all, it only takes time in the beginning. After a while, relatively few files are added and the ones that are will probably access a shallow path.

Another question is this. My code is a library. If I want to distribute it without a source, should I just dump all my headers into one "includes" directory (assuming none have the same name) or should I replicate the directory structure for the library clients?

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
Another question is this. My code is a library. If I want to distribute it without a source, should I just dump all my headers into one "includes" directory (assuming none have the same name) or should I replicate the directory structure for the library clients?
Replicate the directory structure, but provide a "library.h" that includes everything necessary. Most of the boost libraries do this, as does windows.h. This way, you don't have to worry about identical header names, and the user only needs to worry about one include file.

Share this post


Link to post
Share on other sites
How would that affect compilation? Essentially if the client won't use half of the library it will still be compiled into their executable, correct? Or will the linker get rid of the unnecessary stuff?

Share this post


Link to post
Share on other sites
I assume you can include the root path as an include directory, and that the compiler will start searching beneath that?

Currently I'm using things like

#include "../../GUI/gui.h"

in a few files. I would much prefer to leave the backtracking out of it and just include from the root:

#include "GUI/gui.h"

Share this post


Link to post
Share on other sites
Quote:
Original post by CoffeeMug
How would that affect compilation? Essentially if the client won't use half of the library it will still be compiled into their executable, correct? Or will the linker get rid of the unnecessary stuff?

The linker will get rid of the unnecessary stuff. IIRC, the VC++6 linker can only exclude obj modules, i.e. if you use a function from an obj file, it'll pull the whole file into the executable. Later versions come with "Function-level linking" I think.
Not sure what gcc does here...

Share this post


Link to post
Share on other sites

This topic is 4837 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

If you intended to correct an error in the post then please contact us.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this