2

I have 3 classes (it could be 300) , each one with its own header and implementation. I'd like to write an 'elegant' way to organize the way I load of any class needed by every class of the three. Maybe this example helps...

I have : class1 class2 class3

Every header has: 

#ifndef CLASS#_H 
#define CLASS#_H   
  #define FORWARD_STYLE
  #include "general.h"
 #endif

Every implementation has:

  #define DIRECT_STYLE
  #include "general.h"

OK I'm going to write a 'general.h' file in which I'd have : 

#ifndef DIRECT_STYLE 
#ifndef CLASS1_H
#include "class1.h"
#endif
#ifndef CLASS2_H
#include "class2.h"
#endif
#ifndef CLASS3_H
#include "class3.h"
#endif
#endif

#ifndef FORWARD_STYLE 
class Class1;
class Class2;
class Class3;
#endif

// a lot of other elements needed 
#include <string.h>
#include <stdio.h"
....
#include <vector.h" 
( all the class I need now and in the future )

This is a good structure ? Or I'm doing some idiot thing ? My goal is having one unique 'general.h' file to write all the elemenst I need... Are this to work fine ? Thanks

tonnot
  • 435
  • 1
  • 5
  • 17

3 Answers3

4

This might like a fine idea now, but won't scale and should be avoided. Your general.h file will include a vast amount of files, and thus all files that include it will (a) take ages to compile or not compile at all due to memory restrictions and (b) will have to be re-compiled every time anything changes.

Directly include the headers you need in each file, and define a few forward declaration files, and you should be fine.

thiton
  • 35,651
  • 4
  • 70
  • 100
4

The basic rules to follow are:

  1. Let each of your source file include all the header files it needs for getting compiled in a standalone manner. Avoid letting the header files include in the source file indirectly through other files.
  2. If you have constructs which will be needed across most source files then put them in a common header and include the header in Only in those source files which need it.
  3. Use Forward declarations wherever you can.There are several restrictions of when you can get away using them,read this to know more about those scenarios.

Overall it is a good idea to avoid including unnecessary code in source files through a common header because it just results in code bloat, so try and keep it to a minimum. Including a header just actually copy pastes the entire header to your source file and Including unnecessary files has several disadvantages, namely:

  1. Increase in compilation time
  2. Pollution of global namespace.
  3. Potential clash of preprocessor names.
  4. Increase in Binary size(in some cases though not always)
Community
  • 1
  • 1
Alok Save
  • 202,538
  • 53
  • 430
  • 533
0

The #define in a header will probably be ok, but it can propagate through lots of sources and potentially cause problems. More seriously, any time general.h or any of its includes change your entire project rebuilds. For small projects this isn't an issue, for larger projects it will result in unacceptable build times.

Instead, I utilize a few guidelines:

  • In headers, forward declare what you can, either explicitly or with #include "blah_fwd.h" as seen in the standard library.
  • All headers should be able to compile on their own and not rely on the source file including something earlier. This can be easily detected by all source files always including their own header first.
  • In source files, include what you need (usually you can't get away with forward declarations in source files).
  • Also note to never use using in headers because it will pollute the global namespace.

If this seems like a lot of work, unfortunately that's because it is. This is a system inherited from C and requires some level of programmer maintenance. If you want to be able to decide at a high level what's used by your project and let the compiler/runtime figure it out, perhaps C++ isn't the right language for your project.

Mark B
  • 95,107
  • 10
  • 109
  • 188