Re: [boost] [threads] making parts of Boost.Threads header-only

Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: Christopher Jefferson (chris_at_[hidden])
Date: 2009-04-09 13:10:55

On 9 Apr 2009, at 17:34, Emil Dotchevski wrote:

> On Thu, Apr 9, 2009 at 8:17 AM, Frank Mori Hess  
> <frank.hess_at_[hidden]> wrote:
>> -----BEGIN PGP SIGNED MESSAGE-----
>> Hash: SHA1
>>
>> On Thursday 09 April 2009, Anteru wrote:
>>> Dmitry Goncharov schrieb:
>>>
>>> I tend to agree here -- I had to wrap all thread usage behind a  
>>> PIMPL
>>> because previously it would include <windows.h>, which is deadly for
>>> compile times.
>>>
>>> Unless there are very compelling reasons to move the stuff into the
>>> header (like, all other mutex implementations in Boost get removed),
>>> then I can understand it, but otherwise I'd leave it as it is. The  
>>> thing
>>> is, the argument that lightweight_mutex /could/ be removed is bogus
>>> until there is some definite plan to remove it while doing this  
>>> change,
>>> otherwise we'll end up with having both to pay the price of higher
>>> compile times in Boost.Thread and having a mostly redundant class
>>> somewhere else.
>>
>> Isn't arguing that boost::mutex shouldn't be made header-only due  
>> to concerns
>> about compile time even more bogus?  The reason the header-only  
>> suggestion
>> was brought up in the first place was that the code in question is  
>> so trivial
>> it won't impact compile times to put in entirely in the header.
>
> Compile times aren't the issue at all, coupling is. For example, using
> precompiled headers improves compile times but increases coupling.
>
> The benefit of minimizing code in headers is that it increases the
> chance that updating the build after changing the source code will be
> limited to compiling a single CPP file, as opposed to any number (up
> to thousands for large projects) of CPP files when headers are
> modified.

While in general that's true, with a library like boost how likely are  
you to:

a) Change the headers frequently.
b) Not recompile your project on the (rare) occasions when you update  
boost.

Chris