Andrey Semashev wrote:
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).
Yes, I agree. Extracting it as Boost.Ref makes more sense.
boost::checked_deleter is often used with Boost.Intrusive containers, and that code may not necessarily need smart pointers.
Currently Utility depends on SmartPtr anyway, although you are correct that checked_delete has nothing to do with SmartPtr in principle.
It is also not clear why current_function.hpp belongs in Boost.Assert and not e.g. Boost.Config.
The only reason is historical. I wrote it when I wrote assert.hpp. It could go into Config, if John wants to maintain it (which shouldn't be hard as it doesn't change much and the changes are generally trivial.)
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).
Maybe. This was once the case. The problem is ensuring that it stays that way. Every utility component gets put into Utility because, well, where else? And so it grows (as does the list of maintainers that need access to it, which was another problem I was trying to address).