Boost logo

Boost :

Subject: Re: [boost] Extremely large Visual Studio libboost_log_setup* binaries
From: Dave Abrahams (dave_at_[hidden])
Date: 2013-07-13 18:43:06

on Thu Jul 11 2013, Andrey Semashev <> wrote:

> On Thu, Jul 11, 2013 at 12:04 PM, Dave Abrahams <dave_at_[hidden]> wrote:
>> on Wed Jul 03 2013, Eric Niebler <> wrote:
>>>> Remove duplicated code (a big part of Boost.Log is
>>>> a reinvented Boost.Thread). Do not generate so many parsers (type erasure?).
>>>> Created a ticket #8773 (
>>> If Boost.Log is truly that large, I agree with the OP that it's a
>>> problem. An effort should be made to bring the size down to something
>>> reasonable.
>> A possibility not previously mentioned: putting more code in
>> headers/templates, so it is instantiated only as needed.
> But this will move the excessive binary size to the user's code +
> increase user's code compile times.

Not if the user is only exploiting a small fraction of the what goes
into that huge library.

> IMHO, from the user's standpoint this is worse than having a large
> library to link with.

Which user?

It's a tradeoff, and some people will want a different balance than
you've provided.

> I admit that when there are many optional components which may or may
> not be used in the user's code (like in Boost.Spirit, for example),
> this approach is beneficial because it is unrealistic to pre-compile
> all possible combinations of the components. But in case of Boost.Log
> the parsers are self-contained, so the user cannot pick some parts of
> them and reduce the size that way. Selecting character types to
> instantiate parsers on is possible, but even for a single character
> type the resulting binary size is considerable.

Still, if you could cut the binary size substantially by doing that,
maybe you should consider it.

Dave Abrahams

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