Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?

Subject: Re: [Boost-users] Why is there so much co-dependency in Boost? Is there anything to be done about it?
From: Neil Groves (neil_at_[hidden])
Date: 2012-09-05 18:16:14

>
> > I've done a study and written some tools, to determine just how many
> > Boost header files must be included to use some of the Boost modules.
> > The numbers are staggering:
>
> ...
>
> This is a legitimate concern which IMO has not been taken seriously by the
> Boost community.
>

Why do you think this is not being taken seriously? I'm under the
impression that there is disagreement as to the real priority of this
concern. I think that is quite different.

I know I put forward several points that may well be perceived as not
taking this seriously. I was genuinely asking why the OP cared about the
number of included header files. As a technical question I still find it
puzzling to find this a development priority since the solutions involve
considerable development effort and a combinatorial explosion in deployed
configurations. For these disadvantages, if I am to spend time reducing
header file dependencies I require a good reason for expending this effort.
Most arguments about this have centered around satisfying an existing
arbitrary rule in other organisations. While I sympathise with the
developers having to deal with these organisations, it is not compelling
to prioritise this issue over and above the work I would be doing to extend
Boost.Range or deal with trac tickets.

> To some extent it's unavoidable since it's more efficcient to have one
> "best" solution
> imported everywhere rather than replecating code.
>
> But it doesn't have to be as bad as it currently is.  And it's only getting
> worse as more libraries
> get added to Boost.
>
>
Again why is it 'Bad'? This is re-use in most examples I have seen.
Coupling isn't inherently bad. Re-use is coupling.

Specific examples of poor coupling most probably exist. I suspect these
would receive a good response from the Boost development community if these
were specifically raised.

> Here's what  I suggest for boost users such as yourself:
>
> a) don't use "convenience headers" which suck in all the headers in a
> library
> rather than just the one's used.  It seems tedious because one has to read
> more carefully to know which headers to use but it saves huge amounts of
> build time and diminishes "dependency surprises" which can cost a lot of
> time to track down.
>

+1 - Definitely good advice. We Boost developers should provide the option
for the users to make their own choice with respect to having a simple easy
to remember include path with slower compile-times, or more specific
includes. I believe we do that well.

>
> b) a few libraries "infect" your code with "spreading" depencies.  Use your
> analysis to detect these libraries and complain about them.  I have done
> this in the past to no effect.  It did make me feel I was doing something
> though.  If you can't get library authors to see this, you'll just have to
> avoid
> that library or fork your own copy.
>
>
Did you complain about them in trac tickets that have not been resolved? I
definitely am guilty of recently having poor response times to trac
tickets. This is something which I would like to assist in getting
resolved. Of course, if the library maintainer disagrees that the header
file inclusion or dependency is 'bad' then the usual rules apply that the
maintainer has the final say. The benefit of avoiding design by committee
comes at the cost of some disagreement.

> c) In your own code, use pre-compiled  headers.  This speeds up re-builds.
> It DOES force you to spend some time looking at how you've
> divided up your own code but this time is a good investment.
>
>
I'm personally undecided about pre-compiled headers. I find this normally
means that one has considerably increased the amount of included code per
translation unit and therefore generated additional coupling that is far
more significant than the perhaps sub-optimal inclusions within Boost.

> Here's what I suggest library author's do:
>
> a) Take this gentlement's complaint seriously.
>

I would be surprised if any of the Boost developers didn't take this
seriously. My perception is that many of us are not convinced this is a
priority. That isn't the same thing.

> b) Consider eliminating "convenience" headers.
>

I think the Boost library authors are good at choosing the right level of
headers to include. Do you have some specific counter-examples?

> c) When writing documentation avoid depence on "convenience headers".
> This seems like it adds some work - less conveniece - but hels addressing
> this man's problem.
>

I definitely took the approach of using convenience headers in examples. I
did this because the header files were not the primary focus of the example
code. The convenience header in my examples provides code that works while
reducing clutter in my example. I therefore disagree that we should have a
policy of avoiding the convenience headers. Perhaps instead we could
provide additional guidance as to how to use the layers of header files.
However this seems trivially obvious.

>
> Here's what Boost can do. Something like:
>
> a) Formalize the comcept of boost library "levels"
> i) core  - e.g. config, auto-link, BOOST_NONCOPIABLE, ...
> ii) utility - e.g. scoped_ptr, ...
> iii) application support - e.g serialization
>
>
Layering the libraries is a good idea. It would appear to be the only
manageable way of providing more deployment componentisation in sensible
number of tested cohesive units.

> Every boost component would depend only on components at the same or lower
> level.
> The assignment of library level would be part of the review process.
>
> The motivation here is to support the future growth of Boost and C++
> libraries in general.
> I see this as the fundamental requirement behind any efforts to achive
> "Boost Modularization"
>
> Robert Ramey

Neil Groves