Re: [boost] [threads] rework notes

From: Mick Hollins (mick_at_[hidden])
Date: 2005-09-06 09:12:49

Anthony Williams wrote:
> Matt Hurd <matt.hurd_at_[hidden]> writes:
> 
> 
>>This should probably belong on the wiki, but I can't edit in the wiki
>>(access denied).  I've put up a rationale for the thread restructure
>>with basic information as well here
>>
>>http://www.zomojo.com/thread/boost_thread_rework.xhtml
>>
>>Should have some code / structure in place for discussion soon.  First
>>thing to agree on is the basic directory structure and header linkage
>>philosophy.  Moving house over the next couple of days so contact will
>>be a little sparodic.  Note, I'm in Sydney so I work in a different
>>time zone to most.
> 
> 
> Seems like a good start. As for compilers, I generally use VC7.1 and gcc-4.0.1
> (compiled for win32). I have access to VC6 if required.
> 
> I think we should try and make it a header-only library akin to most of the
> rest of boost, if we can; having to link in a separate library is a source of
> pain for users, especially if it has to be linked as a separate DLL. I
> appreciate that there are some areas which might require this, but if we can
> avoid the requirement when these areas are not used, that would be good (don't
> pay for what you don't use).
> 
> Anthony

I am really surprised to see everyone agreeing that a header-only
implementation is preferable. In my day job we have strict rules about
what is allowed to appear in header files, the principal reason being to
reduce dependencies between header files in order to keep compile times
and code bloat manageable. For example, we prefer forward declaring classes over #includes
when possible, we use the pimpl idiom on occasion, we use abstract interfaces
in as much code as possible, etc. All of which help to make for a more
loosely coupled design which has the benefit of minimising the amount
of code that is transitively included in each compilation unit.

I think that boost is an excellent set of C++ libraries, but I have always been
dissapointed by the apparent philosophy of putting
most or all code into header files. I can't remember the details, but
we had one occasion about a year ago where our application's build times increased
fairly dramatically when we upgraded boost versions. We tracked the problem down to a
boost header that we were including having been changed to include another boost header
which ended up transitively bringing in hundreds of header files.

Now I know that making the most of C++'s template mechanisms does imply that more code
will end up in headers than traditional C/C++ code, but to me that is all the more reason to
look extra hard for opportunites to place at least some of the code into .cpp files.

As a user of boost, linking in a few libraries is a minor pain that I am willing to take,
compared to the pain of long build times.

cheers,
mick