Boost logo

Boost :

Subject: Re: [boost] [forward_declare] Interest Inquiry toward Faster Compile Times
From: Julien Nitard (julien.nitard_at_[hidden])
Date: 2012-08-02 03:43:25


On Thu, Aug 2, 2012 at 4:17 PM, Olaf van der Spek <ml_at_[hidden]> wrote:
> On Thu, Aug 2, 2012 at 2:36 AM, Daniel Larimer <dlarimer_at_[hidden]> wrote:
>> I have been increasingly frustrated with how long it takes to compile c++ code. After spending some time in Java and C# I can feel the pain of compile times much sharper than I use to. After seeing that Java and C# were able to achieve some level of generics without requiring 'everything in the header' and knowing that C compiles an order of magnitude faster than c++ I set about to find a way to increase my compile times.
>
> Did you try PCH (precompiled headers)?

Well ... I did, they didn't work for me. Basically PCH resulted in a
huge (200 MB-ish) file to be loaded for each CPP, a good portion of
which was useless. Worse, I had to generate two PCHs : one for my
shared libs and one for my binaries because they were not using the
same compilers options. In addition, GCC options for PCH are not that
easy to use / clear.
What worked was parallel make, though it uses a lot of memory.
Another clumsy and unpracical option was to #include my CPPs in
another a larger one and compile that (it was one solution to another
unrelated problem). It avoids repeating the preprocessing many times.

>> One of the common recommendations is to 'forward declare' everything and to use the PIMPL (private implementation pattern). Unfortunately, PIMPL usually implies heap allocation and if you ever want to return-by-value you are stuck including the entire header for the types you use in your header.
>
> It'd be nice if a future version of C++ allowed pimpl without space overhead.

I am not sure why you are saying this, space is not the problem Daniel
wants to address (though it be nice). Is it related to your message on
std-proposal M.L. ? Daniel (and I ;) cares about Dymanic memory
allocation. Though it would be good to measure whether modern
allocators are very expensive or not ... I.E. if one couldn't replace
forward by pimpl + efficient allocator. It may be worth measuring. I
have been hearing about very efficient malloc implementation for a
while without being able to test them practically. Does anyone have
any experience ?

Regards,

Julien


Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk