Boost Users :
Subject: Re: [Boost-users] Cutting headers
From: Paolo Bolzoni (paolo.bolzoni.brown_at_[hidden])
Date: 2017-05-10 15:14:38
On Wed, May 10, 2017 at 10:36 AM, Paul A. Bristow via Boost-users
>> Unfortunately it is a long standing problem, even Bjarne Stroustrup mentions it.
> 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.
> 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
Boost-users list run by williamkempf at hotmail.com, kalb at libertysoft.com, bjorn.karlsson at readsoft.com, gregod at cs.rpi.edu, wekempf at cox.net