为什么std :: sort似乎会替换向量中的值

Question

The below code snippet shows that std::sort is alternating the values in the vector which is quite confusing.

std::vector<int> a;
std::vector<std::string> b;
std::vector<std::pair<int&, std::string&>> p;

a.push_back(1);
a.push_back(3);
a.push_back(2);
b.push_back("hi 1");
b.push_back("hi 3");
b.push_back("hi 2");

p.push_back(std::pair<int&, std::string&>(a[0],b[0]));
p.push_back(std::pair<int&, std::string&>(a[1],b[1]));
p.push_back(std::pair<int&, std::string&>(a[2],b[2]));

std::sort(p.begin(),p.end());

std::cout << a[0] << " " << a[1] << " " << a[2] <<  std::endl;
std::cout << b[0] << " " << b[1] << " " << b[2] <<  std::endl;

I am expecting it to print

1 2 3
hi 1 hi 2 hi 3

but instead it prints

1 3 3
hi 1 hi 3 hi 3

Why? My compiler is gcc 4.9.3.

I am trying to sort two vectors together and using vector of pairs of references is suggested in https://stackoverflow.com/a/37929675/3667089 .

Answer 1

I would say std::pair<int&, std::string&> is not swappable. std::swap seems to work though, but if you think in a naive swap, it won't work with references

std::pair<int&, std::string&> pair0(a[0],b[0]);
std::pair<int&, std::string&> pair1(a[1],b[1]);

std::pair<int&, std::string&> tmp(pair0);
pair0 = pair1;
pair1 = tmp;

then pair0 gets overwritten by pair1 .

References in general won't work with STL containers.

Answer 2

It's possibly a bug in libstdc++. I added a "debug" comparator to see the sort in action for both libstdc++ and libc++:

std::sort(p.begin(), p.end(), [&] (const auto& ap, const auto& bp)
{
    std::cout << "Debug: " << ap.first << " " << bp.first << " | ";
    for (auto e : a)
        std::cout << e << " ";
    std::cout << " | ";
    for (auto e : b)
        std::cout << e << " ";
    std::cout << "\n";
    return ap.first < bp.first;
});

And this is the output:

Debug: 1 1 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 3 1 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 3 1 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 2 1 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 2 3 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 3 1 | 1 3 3  | hi 1 hi 3 hi 3 
1 3 3
hi 1 hi 3 hi 3
--------------------------
Debug: 3 1 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 2 3 | 1 3 2  | hi 1 hi 3 hi 2 
Debug: 2 1 | 1 2 3  | hi 1 hi 2 hi 3 
1 2 3
hi 1 hi 2 hi 3

For some reason the 2 element gets overwritten by a 3 .

The other possibility is that std::pair<int&, std::string&> does not meet the definition of ValueSwappable . That is, when the actual swapping of elements occur in the sort function, you are experiencing undefined behavior.

Answer 3

The problem is in the insertion sort implementation. Since there are less number of elements, sort decides to perform an insertion sort.

Problematic code:

template<typename _RandomAccessIterator>
    void
    __unguarded_linear_insert(_RandomAccessIterator __last)
    {
      typename iterator_traits<_RandomAccessIterator>::value_type
        __val = _GLIBCXX_MOVE(*__last);
      _RandomAccessIterator __next = __last;
      --__next;
      while (__val < *__next)
        {
          *__last = _GLIBCXX_MOVE(*__next); <<< PROBLEMATIC Code
          __last = __next;
          --__next;
        }
      *__last = _GLIBCXX_MOVE(__val);
    }

Now it goes inside the while loop for the index 2 and index 3 case. Before going into the while loop, __val has the value 2 and hi 2 . But after doing the first move inside the while, __val also changes to 3 and hi 3 and outside the while last is set to 3 and hi 3 , which is incorrect.

UPDATE: libc++ Code in libc++ for this is pretty straightforward and boils down to comparing just 3 values in __sort3 . libc++ uses swap instead of move unlike libstd++ and hence works.

So, seems like moving on reference types is not good as it overwrites the data when the moved element is assigned with new value. Perhaps the same would be the result in libc++ also if we use more than 3 or 4 elements in which case it will also use move under a generic insertion sort routine.

UPDATE 2: Checking more into it, libc++ always uses swap at least for insertion_sort, so no trouble there.

To quote from standard on why references are not good to be stored in container: (Section 23.2)

Containers are objects that store other objects. They control allocation and deallocation of these objects through constructors, destructors, insert and erase operations.

And the table beneath that has this requirement:

X::value_type - T Requires: T is compile time type Destructible

Though I am not sure if reference type is destructible or not. If not, we should better get compile time errors for storing references in STL containers.