Apakah dimaksudkan oleh komite standar C ++ bahwa dalam C ++ 11 unordered_map menghancurkan apa yang disisipkan?

Saya baru saja kehilangan tiga hari dalam hidup saya melacak bug yang sangat aneh di mana unordered_map :: insert () menghancurkan variabel yang Anda masukkan. Perilaku yang sangat tidak jelas ini terjadi hanya pada kompiler terbaru: Saya menemukan bahwa clang 3.2-3.4 dan GCC 4.8 adalah satu - satunya kompiler yang mendemonstrasikan "fitur" ini.

Berikut beberapa kode yang dikurangi dari basis kode utama saya yang menunjukkan masalah tersebut:

#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;
}

Saya, seperti kebanyakan programmer C ++, mengharapkan output terlihat seperti ini:

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

Tetapi dengan dentang 3.2-3.4 dan GCC 4.8 saya mendapatkan ini sebagai gantinya:

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

Yang mungkin tidak masuk akal, sampai Anda memeriksa secara dekat dokumen untuk unordered_map :: insert () di http://www.cplusplus.com/reference/unordered_map/unordered_map/insert/ di mana overload no 2 adalah:

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

Yang merupakan pemindahan referensi universal serakah, memakan apa pun yang tidak cocok dengan kelebihan beban lainnya, dan memindahkan pembuatannya ke dalam sebuah nilai_tipe. Jadi mengapa kode kita di atas memilih overload ini, dan bukan overload unordered_map :: value_type seperti yang mungkin diharapkan sebagian besar?

Jawabannya menatap Anda langsung: unordered_map :: value_type adalah pasangan < const int, std :: shared_ptr> dan kompilator akan berpikir dengan benar bahwa pasangan < int , std :: shared_ptr> tidak dapat dikonversi. Oleh karena itu kompilator memilih overload referensi universal move, dan itu menghancurkan yang asli, meskipun pemrogram tidak menggunakan std :: move () yang merupakan konvensi umum untuk menunjukkan bahwa Anda setuju dengan variabel yang dimusnahkan. Oleh karena itu perilaku merusak penyisipan sebenarnya benar sesuai dengan standar C ++ 11, dan kompiler lama salah .

Anda mungkin dapat melihat sekarang mengapa saya memerlukan tiga hari untuk mendiagnosis bug ini. Itu sama sekali tidak jelas dalam basis kode besar di mana tipe yang dimasukkan ke dalam unordered_map adalah typedef yang didefinisikan jauh dalam istilah kode sumber, dan tidak pernah terpikir oleh siapa pun untuk memeriksa apakah typedef identik dengan value_type.

Jadi pertanyaan saya untuk Stack Overflow:

1. Mengapa kompiler lama tidak menghancurkan variabel yang dimasukkan seperti kompiler baru? Maksud saya, bahkan GCC 4.7 tidak melakukan ini, dan itu cukup memenuhi standar.

2. Apakah masalah ini diketahui secara luas, karena tentunya mengupgrade compiler akan menyebabkan kode yang dulu berfungsi tiba-tiba berhenti bekerja?

3. Apakah komite standar C ++ menginginkan perilaku ini?

4. Bagaimana Anda menyarankan agar unordered_map :: insert () dimodifikasi untuk memberikan perilaku yang lebih baik? Saya menanyakan hal ini karena jika ada dukungan di sini, saya bermaksud untuk menyampaikan perilaku ini sebagai catatan N ke WG21 dan meminta mereka untuk menerapkan perilaku yang lebih baik.

Seperti yang ditunjukkan orang lain dalam komentar, konstruktor "universal" sebenarnya tidak diharapkan untuk selalu bergerak dari argumennya. Ini seharusnya berpindah jika argumennya benar-benar sebuah nilai r, dan salin jika itu nilai l.

Perilaku, yang Anda amati, yang selalu bergerak, adalah bug di libstdc ++, yang sekarang telah diperbaiki sesuai dengan komentar pada pertanyaan. Bagi mereka yang penasaran, saya melihat header g ++ - 4.8.

bits/stl_map.h, baris 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, baris 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)); }

Yang terakhir ini salah menggunakan std::movetempat yang seharusnya digunakan std::forward.

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

Yang merupakan pemindahan referensi universal serakah, memakan apa pun yang tidak cocok dengan kelebihan beban lainnya, dan memindahkannya ke dalam sebuah nilai_jenis.

Itulah yang oleh sebagian orang disebut sebagai referensi universal , tetapi sebenarnya referensi sudah runtuh . Dalam kasus Anda, di mana argumennya adalah lvalue type, pair<int,shared_ptr<int>>itu tidak akan menghasilkan argumen menjadi referensi rvalue dan tidak boleh berpindah darinya.

Jadi mengapa kode kita di atas memilih overload ini, dan bukan overload unordered_map :: value_type seperti yang mungkin diharapkan sebagian besar?

Karena Anda, seperti banyak orang sebelumnya, salah mengartikan value_typewadah itu. The value_typeof *map(baik dipesan atau tidak) adalah pair<const K, T>, yang dalam kasus Anda adalah pair<const int, shared_ptr<int>>. Jenis yang tidak cocok menghilangkan kelebihan beban yang mungkin Anda harapkan:

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