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

Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Emil Dotchevski (emildotchevski_at_[hidden])
Date: 2009-05-29 03:16:49

On Thu, May 28, 2009 at 11:39 PM,  <joaquin_at_[hidden]> wrote:
> Emil Dotchevski escribió:
>> On Thu, May 28, 2009 at 11:15 PM, Joaquin M Lopez Munoz <joaquin_at_[hidden]>
>> wrote:
> My point is that if there's pressure from users to have header-only libs (as
> you and also I recognize) I think the least we can do is try to understand
> and
> analyze these reasons to see their merit. If pressure were the other
> way around (i.e. users demanding that code be moved out of .hpps as
> much as possible) we wouldn't be having this sort of discussions.
>
> 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.

These are indicative of build system problems. It's true, you can work
around build system inadequacies by avoiding building libraries.

> 4. I'm not concerned about ABI issues given that, to start with,
> no ABI compatibility guarantees are provided across Boost versions.

Sure, ABI compatibility is not the issue.

> 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.
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.)

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