Re: [boost] Splitting/rearranging Boost.Utility

Subject: Re: [boost] Splitting/rearranging Boost.Utility
From: Ahmed Charles (acharles_at_[hidden])
Date: 2013-12-11 00:15:45

> From: lists_at_[hidden]
> To: boost_at_[hidden]
> Date: Tue, 10 Dec 2013 23:57:04 +0200
> Subject: [boost] Splitting/rearranging Boost.Utility
> 
> 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.

I agree.

> 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.

current_function.hpp seems to be purely 'config' related, in that it just detects different compilers and how to determine the current functions name.

assert.hpp doesn't depend on anything other than config and current_function.hpp (which would also be config based on the previous point), so whether this goes into it's own library or config probably doesn't matter from a dependency perspective.

ref.hpp going to Bind makes sense and would improve things.

checked_delete.hpp and addressof.hpp are both similar in that they only depend on Config and there has been some discussion of having a repo/library for things that don't depend on anything but Config (perhaps called Core), but that hasn't happened. Though, I'm not sure about using that for user visible things, like this.

> 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.