Re: [boost] [modularization] proposal and poll

Subject: Re: [boost] [modularization] proposal and poll
From: Neil Groves (neil_at_[hidden])
Date: 2014-05-30 12:58:25

On Fri, May 30, 2014 at 5:02 PM, Peter Dimov <lists_at_[hidden]> wrote:

> This only gives the primary dependencies; it would be nice for the
>> finished product to include the secondary module dependencies as well
>> (without going into specifics what included what, just what module brought
>> up the secondary dependency).
>>
>
> And here's the secondary report on smart_ptr. (My initial version listed
> modules in alphabetical order, not in discovery order, which was even more
> stunning as I hadn't the faintest idea why all these modules were deemed a
> dependency.)
>
>
>
> Secondary dependencies for smart_ptr:
>
> <snip>

> range:
>    adds algorithm
>    adds functional
>    adds regex
>
</snip>

I'm not sure this report is giving an accurate representation of the true
dependencies of smart_ptr. Boost.Range only depends upon Boost.Algorithm in
the unit tests and within the collection_traits which I can't imagine you
would use for a smart_ptr. Similarly if you are not using the regex
functionality, smart_ptr will not be dependent on it. The collection_traits
and regex includes are very easily avoided and I believe smart_ptr does not
really depend on these at all. The dependency on Boost.Functional only
occurs if you explicitly include boost/range/iterator_range_hash.hpp

I think that the conditional dependencies by including subsets of headers
is quite frequently used and therefore analysis needs to take this into
account. It could very well be argued that the RegEx adaptor would be
better implemented in the RegEx library. It could also be argued that the
Range-based algorithms might be better placed in Boost.Algorithm. My
rationale for them being in Boost.Range is merely that I have write access
and permission to develop Boost.Range. The coordination effort between
libraries would have been prohibitive initially.

If I am mistaken about your dependencies then please let me know as I
certainly deem it unacceptable that you should not be able to avoid
dependencies on Boost.Regex in particular. I do however agree with one of
your earlier comments to the effect that modularisation would not improve
external quality factors for users but would require a large development
cost. I'm sure we can achieve a lot more useful things with the same
development effort.

Regards,
Neil Groves