Re: [Boost-users] Cutting headers

Subject: Re: [Boost-users] Cutting headers
From: Edward Diener (eldiener_at_[hidden])
Date: 2017-05-10 19:59:48

On 5/10/2017 11:14 AM, Paolo Bolzoni via Boost-users wrote:
> On Wed, May 10, 2017 at 10:36 AM, Paul A. Bristow via Boost-users
> <boost-users_at_[hidden]> wrote:
> 
>>> Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
>>> http://www.stroustrup.com/bs_faq.html#boost
> 
>> The interdependence of Boost libraries isn't a 'problem' - it may be an inconvenience, but is an unavoidable consequence of missing
>> built-in language features and Boost's invaluable working for multiple platforms, targets and compilers and standard versions.
> 
> I find this pattern all the time, so even if a bit out of topic I have
> to ask. Perhaps it is simply a language barrier.
> Since when knowing where a problem come from makes it less a problem?
> You essentially are saying: "Yes, that's the situation. Here why. So
> it's not a problem."
> The problem IS there, if it is unavoidable, or incredibly difficult to
> solve, or "solving it" means to "replace it with bigger problems",
> then it is fine and we live with it. But it does not mean that it's
> not a problem.
> 
> 
>> Work has been done to minimize unnecessary interdependence, but it remains almost impossible to write any library without using some
>> other libraries, as the dependency graphs show.
> 
> True enough, but some interdipendency are a bit gratuitous. Doubly now
> that the standard language gives part of boost.

I wrote a library whose purpose was to reduce the dependence on a Boost 
library when the C++ standard equivalent library was available at 
compile time, while reducing to a minimum any difference in the code 
between using Boost or the C++ standard equivalent, but no one was 
interested. So essentially dependence on other Boost libraries, even 
when the C++ standard equivalent is available via the compiler 
implementation, was not seen as an issue by other Boost developers.

> 
> 
>> There is nothing to stop users figuring out the subset of essential libraries, sometimes quite small, as others have commented.  The
>> downside is that keeping up-to-date may be tiresome.
> 
> "Nothing stops users" is not even an argument. The problem is exactly
> (quoting Stroustrup) that "it [is] hard to pick and choose." Hard does
> not mean impossible.
> 
> Said that, I DO NOT mean at all to say: boost has the problem that the
> libraries are overly coupled and so do not use it.
> Quoting again "it is usually a really dumb idea to go and reinvent a
> wheel that boost already offers," what I mean is: it is infortunate
> and we have to deal with it. Just like with arrays that becomes
> pointers.
>