Question

I’ve just started learning Qt, using their tutorial. I’m currently on tutorial 7, where we’ve made a new LCDRange class. The implementation of LCDRange (the .cpp file) uses the Qt QSlider class, so in the .cpp file is

#include <QSlider>

but in the header is a forward declaration:

class QSlider;

According to Qt,

This is another classic trick, but one that’s much less used often. Because we don’t need QSlider in the interface of the class, only in the implementation, we use a forward declaration of the class in the header file and include the header file for QSlider in the .cpp file.

This makes the compilation of big projects much faster, because the compiler usually spends most of its time parsing header files, not the actual source code. This trick alone can often speed up compilations by a factor of two or more.

Is this worth doing? It seems to make sense, but it’s one more thing to keep track of – I feel it would be much simpler just to include everything in the header file.

Answer 1

Absolutely. The C/C++ build model is …ahem… an anachronism (to say the best). For large projects it becomes a serious PITA.

As Neil notes correctly, this should not be the default approach for your class design, don’t go out of your way unless you really need to.

Breaking Circular include references is the one reason where you have to use forward declarations.

// a.h
#include "b.h"
struct A { B * a;  }

// b.h
#include "a.h"  // circlular include reference 
struct B { A * a;  }

// Solution: break circular reference by forward delcaration of B or A

Reducing rebuild time – Imagine the following code

// foo.h
#include <qslider>
class Foo
{
   QSlider * someSlider;
}

now every .cpp file that directly or indirectly pulls in Foo.h also pulls in QSlider.h and all of its dependencies. That may be hundreds of .cpp files! (Precompiled headers help a bit – and sometimes a lot – but they turn disk/CPU pressure in memory/disk pressure, and thus are soon hitting the “next” limit)

If the header requires only a reference declaration, this dependency can often be limited to a few files, e.g. foo.cpp.

Reducing incremental build time – The effect is even more pronounced, when dealing with your own (rather than stable library) headers. Imagine you have

// bar.h
#include "foo.h"
class Bar 
{
   Foo * kungFoo;
   // ...
}

Now if most of your .cpp’s need to pull in bar.h, they also indirectly pull in foo.h. Thus, every change of foo.h triggers build of all these .cpp files (which might not even need to know Foo!). If bar.h uses a forward declaration for Foo instead, the dependency on foo.h is limited to bar.cpp:

// bar.h
class Foo;
class Bar 
{
   Foo * kungFoo;
   // ...
}

// bar.cpp
#include "bar.h"
#include "foo.h"
// ...

It is so common that it is a pattern – the PIMPL pattern. It’s use is two-fold: first it provides true interface/implementation isolation, the other is reducing build dependencies. In practice, I’d weight their usefulness 50:50.

You need a reference in the header, you can’t have a direct instantiation of the dependent type. This limits the cases where forward declarations can be applied. If you do it explicitely, it is common to use a utility class (such as boost::scoped_ptr) for that.

Is Build Time worth it? Definitely, I’d say. In the worst case build time grows polynomial with the number of files in the project. other techniques – like faster machines and parallel builds – can provide only percentage gains.

The faster the build, the more often developers test what they did, the more often unit tests run, the faster build breaks can be found fixed, and less often developers end up procrastinating.

In practice, managing your build time, while essential on a large project (say, hundreds of source files), it still makes a “comfort difference” on small projects. Also, adding improvements after the fact is often an exercise in patience, as a single fix might shave off only seconds (or less) of a 40 minute build.