Re: [boost] [utility] Moving addressof out of Boost.Utility

Subject: Re: [boost] [utility] Moving addressof out of Boost.Utility
From: Glen Fernandes (glen.fernandes_at_[hidden])
Date: 2014-05-13 18:22:37

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