When working with a library, whether it be my own or external, there are lot of classes with forward declarations. The same classes also have includes as well depending on the situation. When I use a certain class, I need to know whether certain objects that the class uses, are forward declared or are they #include(d). The reason is I want to know whether I should be including both headers or just one.

Now I know it is fairly simple to check, just compile (or go through all the headers until you find the object in question either #include(d) or forward declared). But with large projects, a simple compile takes a long time, and going into each include file to check whether the class in question is being included or forward declared is tedious, especially if it is a few levels deep. To illustrate the problem further:

Class A is a Class B is a Class C which has a pointer to Class Foo

I include Class A and want to know whether Class Foo is ready for use right away, or whether I have to do the following:

#include "ClassA.h"
#include "ClassFoo.h"

So, is there a quick and easy way to find out about this dependency without compiling or going into the depended headers? (one of the reasons I ask this question is becaus开发者_开发技巧e I want to eventually make an add-in for VS and/or stand-alone program for this if the functionality does not already exist)

Thanks!

In a source file you should not depend on what the other header files include.

You should explicitly include every type that your code depends on.
If you do not use a type (ie just passing a pointer or a reference around) then you don't need its definition so don't include its header file (The header file for the methods you are using should have at least a forwward declaration).

So in your particular instance it is hard to tell.
Is you source file explicitly uses any members from Foo then you need to include "ClassFoo.h" otherwise don't. There is no need to go digging around in header files (they may change anyway). Just check exactly what your source file uses and include those (and only those) header files.

In the header file: Prefer forward declaration to inclusion. This way you limit/break circular dependencies.

Actually I am finding eliminating as many header includes as is humanly possible actually helps hella more. See this answer. By cutting out more #include statements, its much more clear exactly what is part of the source file (#includes are a blackbox - you never know what is getting linked in by that one line of text). If a class Foo needs the implementation details of a class Bar, then Foo.h should not include "Bar.h", but rather, contain only a forward declaration. Foo.cpp should include Bar.h.

Foo.h

class Bar ; // fwd declare wherever possible

class Foo
{
  // I can haz needs Bar
  void do( Bar *bar ) ;
} ;

Foo.cpp

#include "Foo.h"
#include "Bar.h" // I can has needs complete implementation details.

Foo::do( Bar *bar )
{
}

Bar.h

class Bar
{
  // code..
} ;

If you're using class A then you should only care about the private interface of the base class C (and possibly additional interface in A. If the class is designed properly, you won't need to access Foo directly because it will be encapsulated in C's interface and not exposed to the public world. In this case you won't need an include to Foo at all because it's not part of C's public interface. If in fact Foo is part of the interface to C in some way, then I argue that C.h should include Foo.h as well, so that clients can use it without having to make the determinations you're asking about.