Re: [boost] [preprocessor] include speed question

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 
mechanism).

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.

Regards,
Paul Mensonides