Subject: Re: [boost] [unordered] a strange limitation for move emulation in Boost.Unordered
From: Joaquin M Lopez Munoz (joaquin_at_[hidden])
Date: 2013-07-08 08:53:16
Daniel James <daniel <at> calamity.org.uk> writes:
> On 8 July 2013 13:25, Joaquin M Lopez Munoz <joaquin <at> tid.es> wrote:
> > Daniel James <daniel <at> calamity.org.uk> writes:
> >> Using move emulation caused some problems:
> >> https://svn.boost.org/trac/boost/ticket/6167
> >> https://svn.boost.org/trac/boost/ticket/6311
> > Yes, but these problems have nothing to do with whether the
> > *elements* of the container are copyable or not, right?
> Oh, you've misread the documentation.
Yes, that was my guess also.
> Perhaps it is a bit ambiguous. I'll change it to:
> * Non-copyable objects can be stored in the containers.
> * Without support for rvalue references the container will not be movable.
> * Argument forwarding is not perfect.
This is much clearer, thank you. Regarding the problem described
at ticket 6167, I think you can solve it and still have move semantics
in pre-C+11 compilers by writing this:
unordered_set& operator=(unordered_set const& x)
unordered_set& operator=(BOOST_COPY_ASSIGN_REF(unordered_set) x)
unordered_set& operator=(BOOST_RV_REF(unordered_set) x)
which is the advice given at
(even if a little confusingly) and happens to be more concise than
what you currently have. The #ifdef guard is needed because
when rvalue refs are supported natively BOOST_COPY_ASSIGN_REF(X)
resolves to const X&.
JoaquÃn M LÃ³pez MuÃ±oz
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk