Boost logo

Boost :

Subject: Re: [boost] [preprocessor] include speed question
From: Paul Mensonides (pmenso57_at_[hidden])
Date: 2012-05-10 13:14:36

On 5/10/2012 9:30 AM, lcaminiti wrote:
> I have a general question about what's the best way to include files that
> results in faster compilation time.
> In my example, I have *a lot* of files that use different parts of
> Boost.Preprocessor. Each header includes the specific Boost.Preprocessor
> headers that it needs. As a results the same Boost.Preprocessor header and
> #included many times (50+?) even if the including has no effect after the
> first inclusion. Furthermore, at the end essentially all Boost.Preprocessor
> header get included.
> This way is more module in that each single file includes all the headers
> that it needs. But, does that slow down compilation? Would it be faster to
> just #include<boost/preprocessor.hpp> just once into a front-end header
> that then includes all my single header files? (Maybe with modern compilers
> and file-systems this makes no difference?)

This is the same-old-same-old and applies to everything, not just the
pp-lib. The way to solve this is with some sort of module mechanism in
the language--which is difficult to do correctly.

Regarding boost-pp specifically, even if you did include
<boost/preprocessor.hpp>, the library itself pulls in specific
dependencies. I personally _never_ use these "group" headers with pp
stuff (and try to avoid it with non-pp stuff). The real reason for that
is not compilation performance but to minimize physical dependencies and
minimize the visibility of names (another potential benefit of a module

I'm not a terribly big fan of auto-dependency generation schemes. I
actually prefer to make an explicit choice about whether to introduce a
dependency. On the other hand, I do like automatically *verified* but
explicit dependencies. For a build system, what I'd actually want (in
addition to the usual) is that 1) there is a means to specify transitive
dependencies such as includes--makefiles are horrible at this without
using some form of automatically generated dependencies which cannot
always be achieved, 2) a means of specifying iterative bootstrapped
scenarios (e.g. LaTeX), and 3) each build action is executed in an
environment where only the specified dependencies "exist"--which would
provide the verification.

Paul Mensonides

Boost list run by bdawes at, gregod at, cpdaniel at, john at