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

Subject: Re: [boost] [threads] making parts of Boost.Threads header-only
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-04-09 12:34:37

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.

Emil Dotchevski
Reverge Studios, Inc.
http://www.revergestudios.com/reblog/index.php?n=ReCode