Question

Consider the following code:

#include <algorithm>
#include <iostream>
#include <vector>

struct A {
   int val;

   bool operator<(const A& other) const {
      std::cout << "operator\n";
      return val < other.val;
   }
};

void swap(A& a, A& b) {
   std::cout << "foo\n";
   std::swap(a.val, b.val);
}

int main()
{
   std::vector<A> a(2);
   a[0].val = 10;
   a[1].val = -1;

   std::sort(a.begin(), a.end());
}

C++11’s std::sort places ValueSwappable requirements on the iterator arguments, move semantics and nothing else, implying that std::sort is “guaranteed” to perform a swap if elements need to be moved around. And 17.6.3.2/3 suggests that my overload definitely ought to be picked in this case.

• Is this correct?

clang 3.1 SVN’s libc++ picks my swap (that is, I see “foo”); GCC 4.6.3’s libstdc++ does not.

• Is this a GCC bug (assuming my standard interpretation is correct)? Or am I missing something?

Answer 1

C++11’s std::sort places ValueSwappable requirements on the iterator arguments, move semantics and nothing else, implying that std::sort is “guaranteed” to perform a swap if elements need to be moved around.

I don’t see that guarantee. Who says std::sort cannot use move semantics instead of swaps? In fact, after browsing the standard for the verbatim specification, I believe this is exactly what happens:

Requires: RandomAccessIterator shall satisfy the requirements of ValueSwappable (17.6.3.2). The type of *first shall satisfy the requirements of MoveConstructible (Table 20) and of MoveAssignable (Table 22).

Note that the iterators shall be ValueSwappable, not the elements they point to.