Project Structure -- where should I place header and source files?

[namnet]

Hello all!

I'm fairly new to both C++ and Code Blocks, so forgive me if my question is stupid -- I simply wonder how to best structure a projects source and header files.

Let's say I have two namespaces and three classes:

app
- GameState

scene
- World
- Entity

... and a file structure that looks like this:

project_home/app/GameState.h
project_home/app/GameState.cpp

project_home/scene/World.h
project_home/scene/World.cpp
project_home/scene/Entity.h
project_home/scene/Entity.cpp

project_home/main.cpp

Now, this gets ugly if GameState has to include World.h (#include "../scene/World.h")

Tracing back the path like this simply feels wrong. How should I avoid it? Keep all my files in the same directory? Put all the headers in an include directory (project_home/include/app/GameState.h) and tell the compiler about it?

How do you do it?

I'm actually used to letting the IDE manage this for me by using some sort of "add class" function, but for all my life I can't find anything like that in Code Blocks.

Thanks in advance!

[killerbot]

Now, this gets ugly if GameState has to include World.h (#include "../scene/World.h")

Tracing back the path like this simply feels wrong. How should I avoid it? Keep all my files in the same directory? Put all the headers in an include directory (project_home/include/app/GameState.h) and tell the compiler about it?

Keep your seperation as you have it. In your project file you specify the include paths of the headers. These are passed on to the compiler as command line options (typically with /I<myDir>), and i nthese paths the compiler will hunt for the header file specified as :
#include "world.h" /// <---- so no extra dirs in here

Tip : specify your paths relatively to the project.

Cheers,
Lieven

[namnet]

Wow, that was the swiftest answer I've ever gotten! Thank you

I actually want have it like #include "scene/World.h" instead of "../scene/World.h", so I can't do as you described above.

[killerbot]

If you want to do it like that, then you have to add the directory containing the scene directory as an include directory to your project.

But if you ever want to restructure your project you will have to change :
 - the include directories of your project (obviously)
 - the code #include "scene/world.h"   -> #include "restructuredscene/world.h"

You can get rid of this latter dependency by adding the scene directory as include dir.

[namnet]

If you want to do it like that, then you have to add the directory containing the scene directory as an include directory to your project.

Yes, I tried doing that but unfortunately the directory that contains the scene directory is my project home, which seemed to make the compiler flip out. I guess I could work around this by adding an extra directory layer, such as "myApp/scene/World.h".

But if you ever want to restructure your project you will have to change :
 - the include directories of your project (obviously)
 - the code #include "scene/world.h"   -> #include "restructuredscene/world.h"

You can get rid of this latter dependency by adding the scene directory as include dir.

Right... I'm beginning to see the upside of doing it that way... A downside is that as soon as I want to add a new directory I'll have to go add it as well.

Thank you for your answers!

[killerbot]

Yes, I tried doing that but unfortunately the directory that contains the scene directory is my project home, which seemed to make the compiler flip out.

Normally this should work.

[killerbot]

I have tried this out and it works. I added the poject home_dir like in your example (I did dir search to it, it was already the default choice, but then it did not allow to turn it into a relative path), and it was add as follows : ../home_dir.

And everything compiled fine (GCC compiler)

[namnet]

Aaah, it had to be a relative path as you said. Thank you, works just fine now!

[Game_Ender]

Codeblocks in a small way encourages bad project layout habits by its project tree layout, at least from the way I see.  I think it is very sloppy to have the header and source in the same directory, you should have parallel trees for header and source files.  If you go one step better you should have a third parallel directory that is just tests for each of your packages. 

In short if you structure you source like below:

Code

project_root/includes/package1/
project_root/includes/package2/
project_root/source/package1/
project_root/source/package2/

You will have a double deep directory in your project tree, Source->source->package1 and Headers->includes->package1.  This has been talked about many times, but until someone sits down and rewrites the 4000 line project tree management code we aren't getting virtual directories.

[namnet]

The problem I see with that is that when adding a class ("new->file->MyClass.h" + "new->file->MyClass.cpp"), one would have to move forth and back through directories. In the long run, these kind of things get really annoying, and is one reason for maybe having all the files in the same directory...

That being said, I'm implementing it now as it seems to be the standard way of doing things.

[Game_Ender]

Well, in the end you are going to spend more time browsing the file trees than you are adding to them.  So the initial overhead of having to put the files in a different place is low compared to the order it gives your project.  It also speeds the search for your compiler when it is trying to find header files.

[killerbot]

another popular division, based upon modular/component split up :

Say I divide my application in logical modules, and out of every module I build a static lib, where in the end the top level of the application will link all those libs together. Then it is well possible that for the implementation of such a module there are several headers and sources, but assume several of those headers are internal to that module (eg : myhelperclass.h, with a myhelperclass.cpp), then it is best to put in this case both the .cpp and the .h in the sources directory, and only headers that are used internal and externally (well basically the interface of this component) are put in the include (header) directory.
So a user of the module does not need to study the implementation files, but can focus on the include directory for the 'interface' headers.


Cheers,
Lieven

[namnet]

Good points! Keep em' comping if you've got more -- I find it quite interesting.