Question

我刚刚失去了三天的生命追踪一个非常奇怪的错误，其中unordered_map :: insert（）会破坏你插入的变量。这种非常明显的行为只发生在最近的编译器中：我发现clang 3.2-3.4和GCC 4.8是唯一的编译器来演示这个“功能”。

以下是我的主代码库中的一些简化代码，用于演示此问题：

#include <memory>
#include <unordered_map>
#include <iostream>

int main(void)
{
  std::unordered_map<int, std::shared_ptr<int>> map;
  auto a(std::make_pair(5, std::make_shared<int>(5)));
  std::cout << "a.second is " << a.second.get() << std::endl;
  map.insert(a); // Note we are NOT doing insert(std::move(a))
  std::cout << "a.second is now " << a.second.get() << std::endl;
  return 0;
}

我和大多数C ++程序员一样，希望输出看起来像这样：

a.second is 0x8c14048
a.second is now 0x8c14048

但是对于clang 3.2-3.4和GCC 4.8，我得到了这个：

a.second is 0xe03088
a.second is now 0

这可能毫无意义，直到你仔细检查http://www.cplusplus.com/reference/unordered_map/unordered_map/insert/处的unordered_map :: insert（）的文档，其中重载号为2：

template <class P> pair<iterator,bool> insert ( P&& val );

这是一个贪婪的通用引用移动重载，消耗任何不匹配任何其他重载的东西，将构造移动到value_type。那么为什么上面的代码选择了这个重载，而不是大多数人所期望的unordered_map :: value_type重载呢？

答案盯着你：unordered_map :: value_type是一对＆lt; const int，std :: shared_ptr＆gt;并且编译器会正确地认为一对＆lt; int ，std :: shared_ptr＆gt;不可转换。因此编译器会选择移动通用引用重载，并且会破坏原始的尽管程序员不使用std :: move（），这是表示你可以使变量被破坏的典型约定。因此，根据C ++ 11标准，插入破坏行为实际上是正确的，并且较旧的编译器不正确。

您现在可以看到为什么我花了三天时间来诊断这个错误。在大型代码库中，插入到unordered_map中的类型是远远在源代码术语中定义的typedef，并不是很明显，任何人都不会检查typedef是否与value_type相同。

所以我对Stack Overflow的问题：

为什么较旧的编译器不会破坏像新编译器那样插入的变量？我的意思是，即使是GCC 4.7也不会这样做，并且它的标准非常符合。
这个问题是否广为人知，因为升级编译器肯定会导致以前工作的代码突然停止工作？
C ++标准委员会是否打算采取这种行为？
您如何建议修改unordered_map :: insert（）以提供更好的行为？我问这个是因为如果这里有支持，我打算将此行为作为N笔记提交给WG21并要求他们实施更好的行为。

Answer 1

正如其他人在评论中指出的那样，“通用”构造函数实际上并不应该总是从它的论证中移开。如果参数确实是一个右值，它应该移动，如果它是一个左值，则复制。

你观察到的行为总是在移动，这是libstdc ++中的一个错误，现在根据对问题的评论来修复。对于那些好奇的人，我看了一下g ++ - 4.8标题。

bits/stl_map.h，第598-603行

  template<typename _Pair, typename = typename
           std::enable_if<std::is_constructible<value_type,
                                                _Pair&&>::value>::type>
    std::pair<iterator, bool>
    insert(_Pair&& __x)
    { return _M_t._M_insert_unique(std::forward<_Pair>(__x)); }

bits/unordered_map.h，第365-370行

  template<typename _Pair, typename = typename
           std::enable_if<std::is_constructible<value_type,
                                                _Pair&&>::value>::type>
    std::pair<iterator, bool>
    insert(_Pair&& __x)
    { return _M_h.insert(std::move(__x)); }

后者错误地使用了std::move，它应该使用std::forward。

Answer 2

template <class P> pair<iterator,bool> insert ( P&& val );

这是一个贪婪的通用引用移动重载，消耗任何不匹配任何其他重载的东西，并将其构建为value_type。

有些人称之为通用引用，但实际上是引用崩溃。在您的情况下，如果参数是类型为pair<int,shared_ptr<int>>的左值，则不会导致参数为右值引用，而不应< / em>离开它。

那么为什么我们上面的代码选择了这个重载，而不是 unordered_map :: value_type重载可能是大多数人所期望的？

因为您和之前的许多其他人一样误解了容器中的value_type。 value_type *map（无论是有序的还是无序的）是pair<const K, T>，在您的情况下是pair<const int, shared_ptr<int>>。不匹配的类型消除了您可能期望的过载：

iterator insert(const_iterator hint, const value_type& obj);

C ++标准委员会是否打算在C ++ 11中unordered_map破坏它所插入的内容？

2 个答案: