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

## 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 on other sites
You can set additional include directories in your project so directory structure won't matter to the compiler.

##### Share on other sites
Quote:
 Original post by MaegaYou 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 on other sites
Well, adding many compiler directories also isn't a very good solution...

##### Share on other sites
Quote:
 Original post by CoffeeMugWell, adding many compiler directories also isn't a very good solution...Does GCC support precompiled headers?

And writing a batch file is? :/

##### Share on other sites
Quote:
 Original post by MaegaAnd writing a batch file is? :/

Took me 15 minutes after Olusei (damn, his name is hard to spell) recommended Python.

##### Share on other sites
Quote:
 Original post by CoffeeMugWell, 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:

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 on other sites
Quote:
 Original post by CoffeeMugTook 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 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 on other sites
Quote:
 Original post by CoderJust 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 on other sites
Quote:
 Original post by JohnBoltonI 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 on other sites
Quote:
 Original post by CoffeeMugAnother 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 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 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 on other sites
Quote:
 Original post by CoffeeMugHow 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 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.

## Create an account

Register a new account

• ### Forum Statistics

• Total Topics
628718
• Total Posts
2984375

• 25
• 11
• 10
• 14
• 14