1

From an Object oriented perspective (mostly C++ and objective C),

Is it a good programming practice to include all header files used in a project into a single (.h), and simply include this header file in all implementation files along with the (right) use of "header guards" and "#pragma once" (or #import)?

What could be the negative implications of this?

Zaxter
  • 2,539
  • 3
  • 24
  • 44
  • 1
    _'A single header file which includes all other header files?'_ ... is probably not a very good idea!! Check here: http://stackoverflow.com/questions/24080478/in-mfc-c-taking-too-much-time-to-build#comment37136245_24080478 – πάντα ῥεῖ Jun 06 '14 at 13:51
  • 3
    Keep it limited to files unlikely to change. – CrimsonChris Jun 06 '14 at 13:56
  • This doesn't have much to do with OOP... – T.C. Jun 06 '14 at 13:57
  • 2
    `What could be the negative implications of this?` Very long compile times because now everything needs rebuilt when any header is changed instead of only the source files that actually need the header. When you have a small project this probably is not much of an issue but when your code includes hundreds of classes this can make your compiles go from seconds to many minutes. – drescherjm Jun 06 '14 at 14:00

1 Answers1

5

It's a pretty bad idea. It will utterly slow down your compilation process. If you have several headers you need access to in every file or most of them, check out precompiled header files (the .pch in xCode). That is the proper way to do it.

Expanding answer: When making a class, you want to include as little headers as possible in .h file. It's better to have them in .m because they don't affect compilation time for other classes that include your header. You ONLY need complete definition of a type in a .h when you need to know it's size in advance. But you ALWAYS know the size of a pointer, so forward declaration is enough:

MyObject.h

#import "MyStruct.h"

@class Foo;  //Forward declaration of Foo.

@class MyObject
{
    Foo *foo; //No problem, you know the size. You can import Foo.h in MyObject.m
    MyStruct struct; //Oops, this is not a pointer. You need to import it's definition right here.
}
@end

MyObject.m

#import "MyObject.h"
#import "Foo.h"

...

- (void)doStuffWithFoo
{
    [foo doStuff]; //If you don't import Foo.h, this will throw a compiler error.
}
Fernando Mazzon
  • 3,363
  • 1
  • 14
  • 19
  • Thanks for the insightful reply. Just for the sake of clarification- I read here (http://stackoverflow.com/questions/439662/what-is-the-difference-between-import-and-include-in-objective-c) that- "The #import line is only replaced by the contents of the named file for the first time it is encountered. Every time after that it is just ignored." So, for header files that don't change, will there still be an increase in compilation time with this approach using #import? – Zaxter Jun 06 '14 at 16:59
  • 1
    It's ignored in the sense that the content doesn't get appended (like it is in plan C when you use #include, thus making you need to use include guards http://en.wikipedia.org/wiki/Include_guard). But you're still adding work the compiling process. Trust me, it really makes compilation much slower in large codebases. – Fernando Mazzon Jun 06 '14 at 17:02