Jump to content
  • Advertisement
Sign in to follow this  
Chrono1081

Header file order of inclusions. Is there a way around this?

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

Let me start off by saying I've read the gamedev article, and various articles online, and many C++ books, and none of them seem to actually answer the question. Here's my question: When including multiple header files is there a good way to do it so that you don't run into issues where the compiler doesn't find things because the #include "blablah.h" is in the wrong order? Let me explain: When I create a header file, it looks like this:
#ifndef _PARENTCLASS_H
#define _PARENTCLASS_H

class ParentClass
{
stuff
};

#endif //_PARENTCLASS_H

I also will have:
#ifndef _CHILDCLASS_H
#define _CHILDCLASS_H

class ChildClass : protected Parent
{
stuff
};

#endif //CHILDCLASS_H

Ok, now what I do is I will list them all in a library header file like so:
#ifndef _LIBRARY_H
#define _LIBRARY_H

//Include files
#include <iostream>
#include "ParentClass.h" //This doesnt work! I have to switch parent and childs
#include "ChildClass.h"  //places in order for them to compile

#endif _LIBRARY_H

Last night I was ripping my hair out trying to figure why my button class didn't see my graphics class and it was all because of the order of my classes. Is there a way around having to worry about order of precedence? I would imagine there would be or else large programs would be a nightmare. I've looked at many online guides and have yet to find one that actually can give a good clear answer that works when I try it. Any help would be greatly appreciated. Thank you. (I've also looked up pragma but I really don't understand how to use it. Maybe this is a solution?)

Share this post


Link to post
Share on other sites
Advertisement
Is this not as simple as having ChildClass.h include ParentClass.h before it defines itself?

That way, if you have

#include "ChildClass.h"

it automatically includes ParentClass.h, and then the next line,

#include "ParentClass.h"

does nothing, since ParentClass.h was already pulled in by ChildClass.h.

Share this post


Link to post
Share on other sites
I tried adding child to parent class first but it didn't work. I thought maybe my syntax was off so I coded two separate classes to test, they worked fine. The only thing that worked was swapping child and parent's order in my library.h file.

Share this post


Link to post
Share on other sites
Oh wait I screwed up what you were saying.

Yes that does work thank you :) When I was trying it last night I never deleted the Child.h which is why I still got compiler errors about too many includes.


In articles I was reading though it said including files like that was bad coding and everything should be stuck in a library file. Is this true?


EDIT: Wait, no it doesn't work :/ I compiled and it worked but once I rebuilt the solution it showed a ton of errors.

[Edited by - Chrono1081 on May 18, 2009 2:10:58 AM]

Share this post


Link to post
Share on other sites
I think you have that backwards.

The parent class doesn't need to know anything about its children.

The child class does need to know about its parent, since it's inheriting everything from it.

Edit:

I don't think having all those includes is bad coding. In fact, I think it's a good thing, since otherwise you can't include Child without knowing it depends on Parent, and you need to include that too. And if you make it depend on something else, or you add additional dependencies, then you have to update your code in lots of places wherever Child was used, where as this way, you don't need to do anything, it just works.

If you want to put all the includes into a single file to make things neat and simple though, go for it.

Share this post


Link to post
Share on other sites
Quote:
Original post by smart_idiot
If you want to put all the includes into a single file to make things neat and simple though, go for it.


You usually want to avoid a master include file. What does work well though, and is a similar concept code wise is a precompiled header. You basically put all your includes into the stdafx.h, and include that in your code files. It is a much better solution then a master file, as its much faster to compile at run time, and is less of a mess.

Share this post


Link to post
Share on other sites
What i always do/did was to make sure that every header file and it's corresponding cpp file compiles for itself.
So, if you inherit from a class or use references, you have to include these files in your header file.
Class members declared as pointers can be forward declared.

Doing so avoids header files including dozens of other files. It works fine for me. :)
In your library header file you only include what you want them to be there.
And if you come across including some structs or whatever what both classes need, think about putting them into a separate header file...

Share this post


Link to post
Share on other sites
Thank you guys for all the suggestions although I'll admit I am still really confused. No book/website I found has been able to explain how to split files well. I understand about the header and C++ files but admittedly completely shy away from them because they never seem to work right.

I've never heard of the stdafx.h file before so I will have to research and see what that is all about. I've seen #pragma used but microsofts documentation on the use of it never explains what it really is or how to use it (unless I'm looking in the wrong place).

Right now I've just been lumping individual classes into header files and leaving it at that and putting all #includes into a library.h file *slaps own knuckles with ruler*.

Share this post


Link to post
Share on other sites
First off, if you are still learning the concepts i'd stay away from precompiled headers for now.
About the other things you asked:

1. #pragma once: This is just another way to tell the preprocessor to only include your header file once into each cpp file. It serves the same purpose as that #ifdef, #define, #endif tripple you put around each header. As with precopiled headers, don't care about that until you have the basics sorted out.

2. Order of inclusion: As has already been said, each class needs to know about every other class it depends on and it's always a good thing to keep things together that belong together. So, if you have a class Child that depends (i.e. derives from) a class Parent, Child needs to know about Parent (not the other way around) so in your Child.h you include Parent.h and it should work. If it doesn't check your other headers, too.

Share this post


Link to post
Share on other sites
Forget about pragmas and stdafx.h for now. You should first understand how to correctly split files and include them, using the standard tools.

Read this thoroughly and post back if something is still unclear.

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.

Participate in the game development conversation and more when you create an account on GameDev.net!

Sign me up!