As your project grows, more and more of your build time is going to be spent waiting for the preprocessor to expand #include's. We actually had to implement an automated single compilation unit solution for our project before the engineers started pulling their hair out waiting for builds to finish after making changes in middle- to low-level libraries. Your compile times technically increase, because you're now compiling a handful of large translation units, but the savings from not having to perform as much disk I/O cut our build times in half. And the engineers didn't mutiny.

EDIT: I should point out that we were already using IncrediBuild, which also benefited from fewer translation units.

Care to elaborate how this is a bad thing? I never ever had an error directly related to forward declaration, and having depencies spread is really a good thing - now if I have to include "X.h" into "Y.h" I can be asured that Y only has the barely minimum depencies that X relies on in its declaration, mostly due to templates/typedefs. Instead of having Y.h now suddenly contain every single include that might be there in the include-chain, which gives you nothing but increased compile times. Even with #pragma once, having all header-files included in other header-files will still lead to recompilation of half your project if you make a change to the header of certain classes.

If I include "X.h" into "Y.h" I would assume both "X.h" and "Y.h" only include what they in turn need. There are going to be dependencies that are required. Whether they are forward declared or they are included is of little difference as far as compilation times are concerned, but when it comes to bug hunting having 1 declaration in 1 file, as opposed to 50 declaration spread over 50 files, will be far easier to manage.

Now what you seem to be implying is that I'm suggesting to dump every header, in every other header, in some massive 'include everything under the sun' paradigm. That is not the case. Each file should be a logical unit or module that handles one or a few related concepts. If your code base is such that manually declaring things in each file results in significantly faster compilation times than including just those headers that are needed, then the problem is with the code base.

To be honest the recommendation to 'always forward declare' and not use #include seems so absurd that I get the feeling something has been misinterpreted, and that this post has somehow gotten off tangent and we aren't actually discussing the same thing.

If your code base is such that manually declaring things in each file results in significantly faster compilation times than including just those headers that are needed, then the problem is with the code base.

Not necessarily. Dependency chains are naturally longer in higher-level code than they are in lower-level code, even if you only ever include precisely what is needed.

but when it comes to bug hunting having 1 declaration in 1 file, as opposed to 50 declaration spread over 50 files, will be far easier to manage.

Are we talking about the same thing?

Class declaration:

class Foo {
    int bar;
}

Forward declaration:

class Foo;

The only thing that needs to be "managed" across 50 files is the name of the class. And if that changes you would have to change the files were it is used either way.

but when it comes to bug hunting having 1 declaration in 1 file, as opposed to 50 declaration spread over 50 files, will be far easier to manage.

Are we talking about the same thing?

Class declaration:

class Foo {
    int bar;
}

Forward declaration:

class Foo;

The only thing that needs to be "managed" across 50 files is the name of the class. And if that changes you would have to change the files were it is used either way.

I'm not trying to be argumentative here, I am truly confused at some of the responses to this post. Apart from the odd circular definition, when do you need one and not the other? I can't think of many places where I need a pointer to an object but never call or access the object in any way?

Though to more directly answer your question, I was more thinking for things like function declarations, enumerations, constants, ect...

I'm not trying to be argumentative here, I am truly confused at some of the responses to this post. Apart from the odd circular definition, when do you need one and not the other? I can't think of many places where I need a pointer to an object but never call or access the object in any way?

Thats why the suggestion is not to include a header of any class where you only need the declaration in another header file. As washu has said, consider this situation:

// Foo.h

class Foo
{
public:
	void func();
}

// Bar.h

// at this point, we don't need to know anything of the foo-class other than that it exists
class Foo;

class Bar
{
public:
	
	void func();
	
private:
	Foo* foo;
}

// Bar.cpp
#include "Foo.h" // at this point, we need the full definition of Foo

void Bar::func()
{
	foo->func();
}