Public Group

# correct order to include...

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

## Recommended Posts

coding for a while on hobby-basis, one thing has never really ceases to occationally eat my time; including stuff it the right "order" so all my classes are declared for al my files. Example: in world.h ___________________________ #ifndef WORLD_H #define WORLD_H #include "main.h" class world{ public: intRect clipRect; etc... } _______________________________ the class intRect is unknown and gets me error. It is declared in var_classes.h which is included in main.h. Main.h looks like this: _______________________________ #ifndef MAIN_H #define MAIN_H #include "funcHGE.h" #include <audiere.h> #include "def.h" #include "var_classes.h" #include "func3.h" #include "func4.h" #include "unit.h" #include "player.h" #include "world.h" #include "audiere.h" #include <list> #include <hge.h> #include <hgesprite.h> #include <hgefont.h> #include <hgeparticle.h> #include <hgecolor.h> extern HGE *hge; extern hgeFont* mainFont; extern hgeFont* largeFont; #include "keyhandler.h" extern globalData glob; extern unitdata data[100]; extern weapondata wData[100]; //sound extern audiere::SoundEffectPtr weaponSound[100]; extern audiere::SoundEffectPtr shootSound[100]; extern audiere::OutputStreamPtr mgSound[10]; extern world * currentWorld; extern unit * theNewUnit; #endif ___________________________________________________ Shouldnt this work? Im sorry if the question is stupid but ive never really learned to understand why and why these things fails me from time to time. Thanks a bunch Erik

##### Share on other sites
Don't put #include "main.h" inside a header, you are asking for circular dependency problems. Put #include "main.h" at the top of every *.cpp file.

##### Share on other sites
ok but then world.h doesnt recognize my cutom classes and i need to include them in my class definitions such as:

class world (is declared in world.h and needs class intRect which is declared elsewere).

##### Share on other sites
It will work, as long as #include "main.h" is at the very top of every cpp file. That's how precompiled headers work and since you are using a global header, I was just thinking that it will work for you too.

Try to avoid having two headers that include each other. The compiler will have a hard time to figure out how to resolve the circular header dependency and sometimes it will include stuff in the wrong order, not what you expect.

Just for the heck of it, what happens when you #include "var_classes.h" in "world.h", just before #include "main.h"? Another solution would be to forward-declare intRect inside "world.h" but I don't know if it will help in this case.

##### Share on other sites
You will have far fewer problems if you follow this simple rule:

A header file should include all the files needed to compile it, and only the files needed to compile it.

Following this rule makes the order of inclusion irrelevent.

[Edited by - JohnBolton on June 25, 2006 12:59:04 PM]

##### Share on other sites
A suggestion for including header files in a source file.

The order of inclusion of header files in a source file is mostly a matter of preference, with the exception of one requirement and one very useful convention. Here is the order that I suggest:
If a PCH file is used, all text before the line that includes the precompiled header is ignored. It can be useful to duplicate the headers in case PCH is turned off and a dummy PCH file is substituted. The drawback is that they can be difficult and/or tedious to maintain. This is rarely done.
• The precompiled header file (if used)
The precompiled header is required to be included before all others because all text before the precompiled header is ignored.
Including the source file's header file before all others (except the precompiled header) is very useful. When you compile the source file, you will also test its header file to make sure it is "self-sufficient". Self-sufficiency is an important quality of header files. Self-sufficient header files do not depend on the order of inclusion, and help catch and prevent circular dependencies.
• All the rest of the header files
The order of the rest of the headers is generally a matter of preference (assuming that they are all self-sufficient). However, sometimes the order might be dictated by coding standards. In the absence of standards, here is a suggestion:
• Group by scope, and order scopes from the most local to the most global. Ordering from the most local to the most global has two purposes: it extends the test for self-sufficiency and it allows local headers to override global/system headers. Is all this important? Not really.
• Within each scope, group by module and order modules alphabetically.
• Within each module, order files alphabetically.

Here's an example source file:
    #include "precompiledheaders.h"        // This file's header file    #include "controller.h"        // Header files in this file's module    #include "gamemenu.h"    #include "menus.h"    #include "preferences.h"        // Header files in sibling or parent modules    #include "System/UserInput/userinput.h"    #include "System/UserInput/vibration.h"        // Header files in unrelated modules    #include "Zap/button.h"    #include "Zap/cycler.h"    #include "Zap/dialog.h"    #include "Zap/zap.h"        // System header files    #include <core/pad_t.h>        // Standard library header files    #include <stdio.h>

##### Share on other sites
Bolton that seems nice but i think that will take even longer time (to figure out which one of loads of files each file need). But if it's failproof it's tempting.

Thanks, ill meddle with this when i get home.

E

##### Share on other sites
Quote:
 Original post by sulimanBolton that seems nice but i think that will take even longer time (to figure out which one of loads of files each file need).

A long time? main.h should include the header files (and only the header files) that declare these symbols:
    HGE    hgeFont    globalData    unitdata    weapondata    audiere    audiere::SoundEffectPtr    audiere::SoundEffectPtr    audiere::OutputStreamPtr    world    unit
But if you are talking about doing this for a lot of header files, then you are right, it does take some time to do this (and to maintain it). But for a project of any meaningful size, you will save a lot of time and headache by spending a little extra time keeping your files organized like this.

Once you start doing it, you will soon see that the header files that are not "self-sufficient" are annoying and time-consuming to deal with. It is very unfortunate that many SDK's don't have self-sufficient header files and it is always a pain to have to figure out which files have to be included and in what order.

1. 1
Rutin
38
2. 2
3. 3
4. 4
5. 5

• 12
• 16
• 12
• 14
• 9
• ### Forum Statistics

• Total Topics
633357
• Total Posts
3011503
• ### Who's Online (See full list)

There are no registered users currently online

×