Re: __rvalref overloads causing ambiguities

[Jonathan Wakely <cow at compsoc dot man dot ac dot uk>]

chris jefferson wrote:

> Here is an attempt at a patch to fix the rvalref ambiguities.

Works for me (I've had something similar in my tree since you suggested
the idea)

> I decided to change the constructors as well as the operator=. The

I did the same.

> constructors weren't causing a problem with this testcase, as there are
> already at least 2 standard-supplied constructors for each container
> (one taking the container, one taking an allocator). However templating

That's true for most, but not for std::pair, so making the rvalref ctor a
template is necessary to prevent this failing:

#include <utility>

struct A {
    template <typename B> operator B() const { return B(); }
};

int main()
{
    A a;
    std::pair<int,int> v(a);
    v = a;
}

(should probably be added to the testsuite, I'll prepare it at lunchtime
if noone beats me to it)

I don't know if the templated ctors are required for the other types.

> Johnathan: I assume you a) have no problems with being put on the
> changelog, and b) I referenced you correctly?

Fine by me, and yes that's the email address I use in the ChangLog, thanks.

> I think the new error message is OK (or at least as OK as error messages
> in the STL ever get...)

You can use the _SameTypeConcept from bits/boost_concept_check to give a
better message e.g.

      template <typename _Moveable>
        deque(__gnu_cxx::__rvalref<_Moveable> __x)
        : _Base(__x.__ref.get_allocator(), 0)
        {
          __glibcxx_function_requires(_SameTypeConcept<deque, _Moveable>)
          this->swap(__x.__ref);
        }

This only works when concept-checking is enabled, but it's better than nothing.

jon