Re: [boost] Splitting/rearranging Boost.Utility

Subject: Re: [boost] Splitting/rearranging Boost.Utility
From: Andrey Semashev (andrey.semashev_at_[hidden])
Date: 2013-12-11 01:20:31

On Wed, Dec 11, 2013 at 1:57 AM, Peter Dimov <lists_at_[hidden]> wrote:
> Currently, Boost.Utility is something of a mixed bag and consequently, a
> dependency knot. Nearly everything in Boost depends on Utility via (say)
> boost/assert.hpp, while at the same time Utility itself depends on much of
> Boost via Iterator (and others). Something Must Be Done.
>
> At minimum, assert.hpp, current_function.hpp, ref.hpp, checked_delete.hpp
> and addressof.hpp need to be moved out. I suspect that call_traits.hpp,
> compressed_pair.hpp, enable_if.hpp also don't belong.
>
> assert.hpp and current_function.hpp should probably go into their own
> library, Boost.Assert. ref.hpp might go to Boost.Bind. checked_delete.hpp
> might perhaps go to SmartPtr. No idea where addressof.hpp needs to go.
>
> These are just suggestions. I'm open to any resolution, as long as the
> dependency (and, to a lesser extent, maintenance) problem is resolved to
> everyone's satisfaction.

I'm not sure moving ref.hpp to Boost.Bind and checked_delete.hpp to
Boost.SmartPtr would result in better dependencies. boost::ref is used
in many libraries, some arguably don't currently depend on Boost.Bind
(I'm thinking of Boost.Phoenix, there may be others). Moving
boost::ref to Boost.Bind would add a dependency but may not remove one
(Boost.Phoenix would still depend on boost::result_of at least).
boost::checked_deleter is often used with Boost.Intrusive containers,
and that code may not necessarily need smart pointers. It is also not
clear why current_function.hpp belongs in Boost.Assert and not e.g.
Boost.Config.

Maybe Boost.Utility should be revised as a collection of tools with
none but the very basic dependencies, like Config and Preprocessor
(this list is just my initial guess, it can be amended). Everything
else could be extracted to distinct libraries.