On Tue, May 13, 2014 at 8:56 AM, Peter Dimov wrote:
My initial idea was to extract Boost.Ref and move addressof there. It doesn't make much sense from a classification point of view... but boost::ref is a client of boost::addressof, libraries often use both and I've been (semi-officially) maintaining them, so...
From a classification point of view, only a Boost.Memory would make sense, I suppose. (Align is probably the closest to being a Memory
library).
A separate module just for addressof also doesn't make much sense.
I should not have suggested it.
Another candidate is probably Config, boost::addressof being ideally a one-liner that imports std::addressof. Unfortunately, some std::addressof implementations at this time tend to fail the boost::addressof tests so it's not that simple. :-)
I haven't checked what the tests cover, but I wonder if any standard library implementation of std::addressof does. The two that I'm aware of are a subset of Boost's implementation (excluding the Borland workarounds). That said, I do like the sound of this - where boost::addressof is provided in Config and is the Boost implementation or std::addressof, depending on whether BOOST_NO_CXX11_STD_ADDRESSOF is undefined.
Andrey's suggested approach of tackling things from the other side and removing everything from Utility that depends on something other than Config also deserves consideration.
I think I drew the wrong conclusions from the earlier discussion about Utility (when you moved Assert out). Utility continuing to live on, for components that have only Config dependencies sounds OK too. I had concerns about taking a [conditional, upon BOOST_NO_CXX11_STD_ADDRESSOF] dependency on Utility because it was a generic utility/common catch-all library that seemed to have many dependencies. Glen