Jump to content
  • Advertisement
Sign in to follow this  
rumpfi88

Include header from previous folder

This topic is 2541 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

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 this post


Link to post
Share on other sites
Advertisement

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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 this post


Link to post
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 smile.png

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 smile.png

Share this post


Link to post
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.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!