Including headers and Main.h

Question

Ok not sure if this is the right way or even a correct way but i have seen this and started to use it, Say you have 6 files

main.cpp
main.h

car.cpp
car.h

speed.cpp
speed.h

• 1st - should you ever have a main.h?
• 2nd - if main.h has #include car.h and #include speed.h then in car/speed.cpp do you just have to add #main.h (thus it would include car/speed.h)
• 3rd - should you ever go that route?

Solution 1

#include minimalistically. The reason behind an include should be that, if removed, the code doesn't compile.

Don't #include when you can forward-declare. If "Class A;" will suffice, don't #include a.h.

In particular, prefer to forward-declare in header files, avoiding nested includes which generate highly coupled mega-include files.

See also Self-sufficient header files, in a related question.

Solution 2

1) Only if you need to expose something in main.cpp to other cpp files, so depends on what it has.

2) Possible but not recommended.

3) For a number of reasons (code design, compile time, etc), you want to include as little as needed. Additionally, its convention for your class to have a .h and a .cpp and for one to directly include the other. You should also try to include headers in your .cpp files, and try to avoid headers including headers where possible.

Solution 3

No typically there is no main.h. I believe it is good practice to include all headers you need in the source file not only in the header. If you rely on the headers to include everything you need it may happen that a change in a header breaks your source file.

Solution 4

1st - should you ever have a main.h?

Very rarely. main.cpp implies it's compiling the translation unit that contains main(), which is typically client code for other lower-level libraries that shouldn't need to know about the symbols in main(). If somehow things got cyclic in your design, and there was good reason (massive time pressure?) not to split something you'd put out into a separate .cpp, then you could end up with a main.h. That should really only declare the symbols in main.cpp that other translation units might need access to. Specifically, it shouldn't include car.h and/or speed.h unless exposing main.h functions that need car.h or speed.h declarations - for example, a declaration of a function in main.cpp that took arguments of types from car.h or speed.h.

2nd - if main.h has #include car.h and #include speed.h then in car/speed.cpp do you just have to add #main.h (thus it would include car/speed.h)

As above, this is almost certainly a very broken design: main.cpp would be expected to include car.h and speed.h directly, and if it doesn't want to do that and a higher-level header is needed for car.h and speed.h, it should be named based on their overarching theme (e.g. transport.h), not named after the specific client that wants access to both. Remember, main.h should only exist if it's necessary to expose things from main.cpp.

3rd - should you ever go that route?

Probably not, given what I've explained above.

Solution 5

It is not typical to have a "main.h" - but there's certainly no rule that forbids it.

As to what needs to be included, and how you achieve that, really depends on what the respective classes do, what knowledge of each other they need.

It is generally considered a bad idea to have "one include file that includes everything else" in the style you describe. For several reasons: 1. It is hard to see which source file depends on which includes. 2. You get longer compilation time as the compiler has to read through a bunch of class definitions that aren't being used. 3. You can't easily take, say, "car.h" and "car.cpp" and stick them in another project without "speed.h".

View more solutions