On Aug 1, 2013, at 6:04 PM, Krzysztof Kosiński wrote:
2013/8/1 Jon Cruz <jon@...18...>:
Another general problem with bodies in headers is that if they are not trivial then they need to pull in other includes to be able to do their job. That 'contaminates' consumer .cpp files with more includes than absolutely necessary. Compile times for the project then go up.
This is a legitimate issue, but it is only relevant in this case:
#include <big-object.h> #include <mammoth-object.h> #include <gargantuan-object.h>
class SimpleClass { public: ... private: BigObject _x; MammothObject _y; GargantuanObject _z; };
Instead of hiding the three member objects in a pimpl, one can convert _x, _y and _z to pointers, in which case only forward declarations are necessary. This is more readable, because one doesn't need to track down the definition of the pimpl structure to know the members of the class.
Actually, that's not the only relevant case.
First, even seemingly small include files can add up to measurable compile-time differences. And I've even worked on projects where enabling pre-compiled headers (a work-around designed to address just such time issues) end up making the end-to-end compile go slower instead of faster. In one case it was only about minute difference, but since it was on a compile that took under five minutes normally that ends up impacting developers.
Even this case can have a significant measured difference:
#include "forward.h"
class SimpleClass { public: ... private: int _x; int _y; int _z; };
In this case, I've seen bad headers (aka too-inclusive instead of relying on simple forward declarations) increase parse/compile time for a .cpp by an order of magnitude or two. A key point is that it doesn't matter if there are member types that are complex, only if an include happens to include another include that includes some includes that take the compiler a while to parse.
(The mention in the example of using three pointers is a completely different issue.)