C++17 In Detail

16 February 2013

Why is it building so long?

See my new website at cppstories.com

Most of Object Oriented guides revolve around the word encapsulation: we should hide implementation details of a class and reduce coupling between objects as much as possible. But, in C++ (and also in other compiled languages) we also need to care about the physical side of the design.

How can we do that?


Here is a 'common' style of class declaration:
#include "Engine.h"
#include "Gearbox.h"
#include "..."
#include "Wheels.h"

class Car
    Engine m_engine;
    Gearbox m_gearbox;
    Wheels m_wheels;
    Car() { }
    virtual ~Car() { }
    void drive() { }
    void checkInternals();
Assume the logic design is good. What are the problems related to physical side of such class?
First thing: what if we add a method in the Engine class? Not only the Car.cpp will have to be compiled again (this is expected of course), but clients of the Car class as well!
Second thing: what if we change/add some private method or a private field of the Car class? That way clients also have to be recompiled.
What is the point? Why is it important? For small projects there is almost no difference between good and bad physical design. But when project is large need for recompilation means long (very long and even longer) building time.
Do clients of a class need to be recompiled every time? Do they need to know its internal guts - private fields and methods?
Additionally although clients can assume that the (public) interface of a class will not change, it is not the same as with the compiler. It depends on all information in header files, so even if a private implementation of a module is changed, than every dependent module is needed to be compiled again.
The tool that could help us in improving the physical side the design is called insulation, see below some result of applying that
Isn't that a bit better?
class Engine;
class Gearbox;
class Wheels;

class Car
    std::unique_ptr<Engine> m_engine;
    std::unique_ptr<Gearbox> m_gearbox;
    std::unique_ptr<Wheels> m_wheels;
    virtual ~Car();

    void drive();
    void checkInternals();
Or even:
class Car
    std::unique_ptr<class CarImpl> m_pImpl;
    virtual ~Car();

    void drive();

    // private methods 'moved' to source file...
Can you see the difference? Will it compile/build faster?

About the book

This blog post is a result of skimming (and some reading) of the book called "Large Scale C++ Software Design", by John Lakos. This is advanced C++ book, but touches a unique topic in the area: how to design code not only from logical perspective but from physical side as well.
Sometimes the writing style is a bit 'academic' and hard to understand quickly. But all in all it is a great source for everyone involved in creating something bigger than, let's say, 10 000 lines of code.
Main flaw: it is a bit old: from 1996, and it even uses Booch diagrams... I wish there is a second, newer edition. But still lot of theories are so general that even now we can use them.

It appears that soon we'll get a nice refresh of the book:

This new book "Large-Scale C++ Volume I: Process and Architecture" is scheduled for September 2016. It's volume I, so we can expect more volumes in the following years.

There is also a lot of existing (and usually free) content from John Lakos, for example

Sorry for the interruption, let's go back to the original article... :)

Insulation definition

So what is this insulation? Let us see what author says about that:
A contained implementation detail (type, data, or function) that can be altered, added or removed without forcing clients to recompile is said to be insulated.
What can we do to reduce this physical coupling then?


When we declare an argument in a method: void func(A a, B b); compiler has to know the details of A and B. So the simplest way is to include A.h and B.h at the top of our header. But actually we need such details only in the implementation of func, it is not needed in (pre)declaration.
It is better to use const pointers or const references for such arguments (of course for built in types there is no such need). When compiler sees const A *a it has to know only the name, not full definition of particular type.


As with methods' parameters, we can use similar technique regarding class members. It can be easily seen in our Car class - the second version. This time we need only predeclarations of particular classes.
Unfortunately this comes at a price: we need to allocate those members somewhere on the heap in the implementation file (in constructor for instance). For large members it is even better, but for small classes (for instance like Vector3) it can be to tricky.


One of the most radical method is to use pImpl pattern. It can be seen in the third version of the Car class. Everything private goes to class named pImpl that is declared and implemented in the cpp file. That way client of Car does not see its guts. And we do not have any additional includes and physical coupling.

Private methods

Keep private stuff private.
When we see a class and its private: block, we can assume how it works. It is better to diminish this block and move every method to implementation file. How? It is not that easy unfortunately.
We can create a static free function in cpp file, but that way we have no access to private members of the class. It is pointless to create a static member function of the class because it is almost the same as the original method (we need to declare this in header file as well).
Sometimes it is good to go through all private methods and check if they really should be in this class? Maybe they should be removed or moved to some helper class, or even made a free function?


Insulation is not a silver bullet for everything. Is it good to insulate small Point2D class? Probably not! We would make more harm actually. Below there is a list of issues to consider before doing full, hardcore insulation:
  • Lower performance: when doing insulation lots of variables are placed on the heap, for small piece of data it can be harmful.
  • It is not that easy to fully insulate a class. We need time (and skills) to do that.
  • Maybe our class is not used that often, maybe there will be no difference in compilation time whatsoever?
Below there is a picture that could suggest when to insulate (grabbed from the book):

Sum up

It is just a tip of an ice berg! As I mentioned earlier I did not cover include topic and some other stuff like: enums, protocol class, handles and opaque pointers. But I hope that this post gives you a motivation to look at your code from a bit different perspective.

The book

Large-Scale C++ Software Design
New version: Large-Scale C++ Volume I: Process and Architecture
This article also is hosted on: www.codeproject.com

As usually, logo comes from: openclipart

If you want to get additional C++ resources, exlusive articles, early access content, private Discord server and weekly curated news, check out my Patreon website: (see all benefits):

© 2017, Bartlomiej Filipek, Blogger platform
Disclaimer: Any opinions expressed herein are in no way representative of those of my employers. All data and information provided on this site is for informational purposes only. I try to write complete and accurate articles, but the web-site will not be liable for any errors, omissions, or delays in this information or any losses, injuries, or damages arising from its display or use.
This site contains ads or referral links, which provide me with a commission. Thank you for your understanding.