C ++ 11でunordered_mapが挿入したものを破棄することは、C ++標準委員会の意図ですか？

unordered_map :: insert（）が挿入した変数を破壊するという非常に奇妙なバグを追跡して、3日間の人生を失ったところです。この非常に明白でない動作は、ごく最近のコンパイラーでのみ発生します。clang3.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（）のドキュメントを詳しく調べるまで意味がありません。

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

これは、他のオーバーロードのいずれかに一致しないものを消費し、貪欲普遍参照ムーブオーバーロードされ、そして構築移動 VALUE_TYPEにそれを。では、なぜ上記のコードがこのオーバーロードを選択したのでしょうか？

答えはあなたを正面から見ています：unordered_map :: value_typeはペア< const int、std :: shared_ptr>であり、コンパイラーはペア< int、std :: shared_ptr>は変換可能ではないと正しく認識します。したがって、プログラマーがstd :: move（）を使用していないにもかかわらず、コンパイラーはユニバーサルムーブリファレンスのオーバーロードを選択し、元のオブジェクトを破棄します。そのための行動を破壊し、インサートは、実際には正しい C ++ 11標準あたりとして、そして古いコンパイラであった正しくありません。

私がこのバグを診断するのに3日間かかった理由が今わかるでしょう。unordered_mapに挿入される型がソースコード用語で遠く離れて定義されたtypedefである大規模なコードベースではまったく明らかではなく、typedefがvalue_typeと同一であるかどうかを確認することは誰にも起こりませんでした。

スタックオーバーフローへの私の質問：

1. 古いコンパイラーが新しいコンパイラーのように挿入された変数を破棄しないのはなぜですか？つまり、GCC 4.7でもこれは行われず、かなり標準に準拠しています。

2. コンパイラを確実にアップグレードすると、以前は機能していたコードが突然機能しなくなるため、この問題は広く知られていますか？

3. C ++標準委員会はこの動作を意図しましたか？

4. unordered_map :: insert（）を変更して動作を改善することをどのように提案しますか？ここでサポートがある場合は、この動作をWG21へのNノートとして送信し、より良い動作を実装するように依頼するつもりなので、これを質問します。

他の人がコメントで指摘したように、「普遍的な」コンストラクタは、実際には、常にその議論から離れることを想定されていません。引数が実際に右辺値の場合は移動し、左辺値の場合はコピーすることになっています。

あなたが観察する行動は、常に動きますが、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。

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

これは、貪欲なユニバーサル参照移動オーバーロードであり、他のオーバーロードと一致しないものを消費し、それをvalue_typeに移動します。

これは一部の人々が普遍的な参照と呼んでいるものですが、実際には参照が崩壊しています。あなたのケースでは、引数がどこにある左辺値の型のpair<int,shared_ptr<int>>それはなりません引数は右辺値参照であることになり、それはいけません、そこから移動します。

では、なぜ上記のコードがこのオーバーロードを選択したのでしょうか？

あなたは、他の多くの人々と同様value_typeに、コンテナ内のを誤って解釈したためです。value_typeのは*map（注文または順不同かどうか）であるpair<const K, T>あなたのケースです、pair<const int, shared_ptr<int>>。タイプが一致しないと、予想されるオーバーロードが解消されます。

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