Re: [boost] [unordered] a strange limitation for move emulation in Boost.Unordered

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:

// Assign

#if defined(BOOST_NO_CXX11_RVALUE_REFERENCES)
unordered_set& operator=(unordered_set const& x)
{
    table_.assign(x.table_);
    return *this;
}
#endif

unordered_set& operator=(BOOST_COPY_ASSIGN_REF(unordered_set) x)
{
    table_.assign(x.table_);
    return *this;
}

unordered_set& operator=(BOOST_RV_REF(unordered_set) x)
{
    table_.move_assign(x.table_);
    return *this;
}

which is the advice given at

http://www.boost.org/doc/libs/1_54_0/doc/html/move/emulation_limitations.html#move.emulation_limitations.assignment_operator

(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
Telefónica Digital