On Tue, May 13, 2014 at 8:13 AM, Andrey Semashev wrote:

Is there really a reason to create a submodule for a single header?

I thought we've settled the dependencies of Boost.Utility by moving some components to separate submodules. Extracting addressof.hpp won't remove any dependencies.

Ideally there would be a more sensible home for addressof (e.g. if there was a Boost.Memory or similar library). I probably misinterpreted the outcome of the discussion on Utility. I thought the plan was to eliminate it, and move its contents into more appropriate existing libraries (or create tiny libraries for them). Keeping Utility around but enforcing that nobody adds anything to it that would bloat its dependencies seems fine too, although perhaps less easy to achieve. Glen

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

On Saturday 17 May 2014 14:14:19 Ahmed Charles wrote:

...

Date: Tue, 13 May 2014 15:22:37 -0700 From: glen.fernandes@gmail.com To: boost@lists.boost.org Subject: Re: [boost] [utility] Moving addressof out of Boost.Utility

On Tue, May 13, 2014 at 8:56 AM, Peter Dimov wrote:

...

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.

How far are we from the goal of having utility only depend on Boost.Config? Is help needed in this area, if it's the direction we wish to go?

There was this discussion with the needed steps: http://thread.gmane.org/gmane.comp.lib.boost.devel/247282/focus=247309 I think, the situation hasn't changed since then.