# Include header from previous folder

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

## Recommended Posts

I finally started my project of creating a game (for the start with console). I put the classes into folders (i.e. Characters, Spells etc.) with abstract classes and the objects into another folder (i.e. Characters/NPC and Characters/Monsters).

To stay at folder "Characters" where my abstract class is I created in "Characters/Monsters" a new class "Goblin". Now I want to derive from Characters.

 #include // I don't know the path, that's the problem class Goblin : public Characters { // variables and (virtual) methods, I needn't know the details }; 

Do you have a clue how to include the abstract class's header?

##### Share on other sites

I finally started my project of creating a game (for the start with console). I put the classes into folders (i.e. Characters, Spells etc.) with abstract classes and the objects into another folder (i.e. Characters/NPC and Characters/Monsters).

To stay at folder "Characters" where my abstract class is I created in "Characters/Monsters" a new class "Goblin". Now I want to derive from Characters.

 #include // I don't know the path, that's the problem class Goblin : public Characters { // variables and (virtual) methods, I needn't know the details }; 

Do you have a clue how to include the abstract class's header?

set the base project directory as an include directory in the project settings and then do #include "Characters/whatever.h";

(To include from the parent folder you can use #include "../whatever.h" on some platforms, but in general it isn't a great idea)

##### Share on other sites

(To include from the parent folder you can use #include "../whatever.h" on some platforms, but in general it isn't a great idea)

thanks, this helps. I forgot the command for parent folders.
I'm using VC Studio 2010 as IDE (maybe I'll test the game on Ubuntu as well). Wish me luck for my first game.

lg rumpfi88

##### Share on other sites
To reiterate SimonForsman's warning, it's not a great idea to use relative paths when doing header inclusion. IMO, the other suggestion is the one to pick given the choice, as it is more robust to project reorganization.

##### Share on other sites

To reiterate SimonForsman's warning, it's not a great idea to use relative paths when doing header inclusion. IMO, the other suggestion is the one to pick given the choice, as it is more robust to project reorganization.

My project will have around 100-200 classes, maybe even more. How else should I organize the project?

##### Share on other sites
Your idea of organizing the source files in subfolders is fine, all edd² and SimonForsman wanted to say is, that it is (in general) not a good idea to rely on relative paths for your imports (i.e. do the #import "../whatever.h"), but to add the project's base folder to your include directories and do the include like this: #include "Characters/whatever.h".

##### Share on other sites
I tryed to say "Characters/......h", but it didn't work. I only get a list of header-files in the project within that folder.

Edit: Now it worked, I wrote the wrong include direction xP

##### Share on other sites

(To include from the parent folder you can use #include "../whatever.h" on some platforms, but in general it isn't a great idea)

Hmm, I've been using relative includes (stuff like ../Utilities/Bla.h) for ages. The file doing the including would be part of the same module / package / whatever you want to call it as the included file. Can you elaborate on why this is considered a bad idea?

##### Share on other sites

Hmm, I've been using relative includes (stuff like ../Utilities/Bla.h) for ages. The file doing the including would be part of the same module / package / whatever you want to call it as the included file. Can you elaborate on why this is considered a bad idea?

Well, it certainly works which is the most important thing, so don't feel pressure to change

I can't speak for SimonForsman, but I avoid relative inclusions for a couple of reasons.

First, when you write '#include "../abc.h"' is the path relative to the header doing the including, or are include paths taken in to account? Is this the same across all compilers? I honestly don't know, but I suspect include paths are looked in before abc.h is sought relative to the directory of the file doing the including. It's something you can look up of course, but In my case I'm targeting three operating systems and five or so compilers, so I'd rather not have to worry about that kind of thing. YMMV.

The second reason can be illustrated by using the O.P's hypothetical situation. Suppose we have:

• Character.hpp // contains abstract base class
• Monsters/Goblin.hpp // class Goblin : public Character { ... }
• Monsters/Dragon.hpp // likewise
• Monsters/Mutant.hpp // likewise
• Monsters/Houndeye.hpp // likewise

In Monsters/Goblin.hpp, for example, we could have '#include "../Character.hpp"'. Again, that's fine and will work, but if I later decided that I'd like "Game" to contain only the more general engine code and move the specific monsters out in to a separate project that's built on top of the engine module, I have to change those include paths. It sounds rather hypothetical, but I end up doing this quite a lot. For example, in the past month or so, I've extracted code for the following things in to their own projects, in order to make them more reusable:

• handling unicode (#include "unicode/xxxx")
• wrapping SSE intrinsics (#include "vx/xxxx")
• timing and benchmarks (#include "chrono/xxxx")
• handling task-based parallelism (#include "hive/xxxx")

If I'd have used relative paths, I'd have had a lot of busy work to do. But all I had to do was change a couple of include paths in what were the surrounding projects and everything continued to work.

It's probably the case that I'm more aggressive than most about moving reusable code out in to sharable modules, but I don't think that's necessarily a bad thing

##### Share on other sites
Well, I certainly tend to do a lot of reorganizing / refactoring, and it's true that I've had to adjust a lot of relative includes in the process, so you do have a point there.

• ### Game Developer Survey

We are looking for qualified game developers to participate in a 10-minute online survey. Qualified participants will be offered a \$15 incentive for your time and insights. Click here to start!

• 15
• 11
• 9
• 11
• 15