Re: [boost] [Modularization] A new approach to header modularization

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: joaquin_at_[hidden]
Date: 2009-05-29 03:28:41

Emil Dotchevski escribió:
> On Thu, May 28, 2009 at 11:39 PM,  <joaquin_at_[hidden]> wrote:
>   
>> As a user, I can describe *my* reasons to favor header-only libs:
>>
>> 1. The whole bjam-driven building process is nontrivial and time and
>> space consuming.
>> 2. If autolinking is not available, picking up the right lib variant is not
>> trivial.
>> 3. Bulding libs selectively is not as easy as it might seem, due to the
>> fact that interlib dependencies might force you to build libB when using
>> libA, and you don't know in advance.
>>     
>
> [...]
>
>   
>> This is not to say that I'd like *every* lib to be header-only; but
>> I'd say the benefits of moving to a link-based lib should be balanced
>> against points 1-4.
>>     
>
> Assume for a moment that 1-3 were solved at the build system level.
>   

Assuming 1-3 were solved is tantamount to assuming that building libs is as
painless as not having to build them. Under these conditions of course 
I'd have
no reason to prefer one solution to the other.

> What reasons do you have for putting code in headers? I can think of
> only two:
>
> - Code that must be there, e.g. templates
>
> - Performance reasons: 1) inlining functions and 2) not using pimpl in
> code that is provably critical (the price is greater physical
> coupling.)
>   

These are points for a lib developer to evaluate, not the Boost user. 
Remember we were
talking of reasons why users prefer header-only.

Again, I've listed here my personal reasons (as a user). I think it 
could be instructive to
try to gather more insight as to why our users prefer header-only libs, 
putting aside
our own arguments as Boost authors.

Joaquín M López Muñoz
Telefónica, Investigación y Desarrollo