Header hell

[closed account oivD8vqX]

I was following a tutorial and found myself in header hell, so I did what I always do; I defined a master header and put the master in every file or header I had.

It solved the problem, but I'm wondering is there any downside to doing this as long as I wrap each header in a guard?

Here is the master header in case I'm not using the correct jargon. My problem was master gms_panels.h needed gms_communicate.h and vice-versa.

#ifndef gms_headers_h
#define gms_headers_h

#include <wx/wx.h>
#include <gms_panels.h>
#include <gms_communicate.h>
#include <main.h>

#endif

[dutch]

This seems like overkill.
If class A refers to class B and B refers to A then you can usually solve it something like this:

// a.h ==============================================

class B; // Simply let A know that B exists.

class A {
    B* b; // can only hold a pointer (or reference)
};


// b.h ==============================================

#include "a.h"

class B {
    A a; // This can have pointer or actual object
         // since it sees A's definition.
};

[jonnin]

a 'master' header file is fine in some situations, esp for a large file-rich library where you either need all of it or a very specific subset is used over and over.

a few drawbacks:
1) you mixed 3 things in one header. stuff you wrote (?) (main), wx stuff, and gms stuff. this new header is useless outside of one program, most likely, so you have to re-do this idea if you have another project.
2) you may include stuff you don't need at times. The compiler usually sorts this out, but it CAN cause bloat if it gets confused.
3) if you are careless with these, they tend to do one of two things. they get too large, because you keep adding to them for each new project, or worse, you have multiple versions of this file out there in your code base, no two exactly alike.

if you do this idea, some advice:
-if this gets bigger, have one for wx, one for gms, one for the project specific items. keep them organized. The project specific one can be the 'true master' and pull in the others so you only need to include one of them in the real code base.
-consider some #ifdefs to cut out what isnt needed, in groups, if they get large. I prefer 'must have this to include it' over 'if has this, don't include it' approach. eg #ifdef using_wx, #ifdef using_gms, ...
- do what dutch said if you wrote the libraries. For stuff you download, tampering is 'bad' because the tampering is cleared out if you get a new version later. I don't see that doing what he said into your own wrappers over the original stuff is any better, for downloaded tools.