Boost logo

Boost :

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

Emil Dotchevski
Reverge Studios, Inc.

Boost list run by bdawes at, gregod at, cpdaniel at, john at