Subject: Re: [boost] [Modularization] A new approach to header modularization
From: Vladimir Prus (vladimir_at_[hidden])
Date: 2009-05-29 02:49:03
> Emil Dotchevski escribiÃ³:
>> On Thu, May 28, 2009 at 11:15 PM, Joaquin M Lopez Munoz <joaquin_at_[hidden]> wrote:
>>> Emil Dotchevski <emildotchevski <at> gmail.com> writes:
>>>> On Thu, May 28, 2009 at 10:50 PM, <joaquin <at> tid.es> wrote:
>>>>> Why there's pressure from users to keep Boost libs header-only? Boost is
>>>>> for the users, so their reasons should be given proper weight.
>>>> One can not create good design (in general, not just in software) by
>>>> asking the users what would they like.
>>> I'd rather not go into discussing such far-reaching issues
>>> as design theory, but you haven't asked my question:
>>> What are the particular reasons why users demand header-only
>> Probably different users have different reasons. One reason might be
>> that it makes Boost easier to install initially. What's your point?
> 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.
It it my understanding (based on actually supporting users on IRC and
mailing lists for years), that the users who are mostly concerned about
linking are either:
1. Users who just crossed the chasm between the two popular platforms,
in either direction.
2. Users who don't understand the difference between headers and libraries
in general, and don't know how to use their IDE.
3. Users who don't know C++.
Users in (1) group will adapt quickly. Users in groups (2) and (3)
probably won't be able to use Boost effectively until they do some
> 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.
In 1.39, it is two commands in 1.39, on popular platforms. And processors
are fast these days.
> 2. If autolinking is not available, picking up the right lib variant is not
It is not an issue on GNU/Linux.
> 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.
And you should not care. If you add --with-filesystem, then the system
library will be built automatically.
> 4. I'm not concerned about ABI issues given that, to start with,
> no ABI compatibility guarantees are provided across Boost versions.
The fact that there's no ABI compatibility (or API, either), is a big
problem in itself.