Ist es vom C ++ - Standardkomitee beabsichtigt, dass unordered_map in C ++ 11 zerstört, was es einfügt?

Ich habe gerade drei Tage meines Lebens verloren, als ich einen sehr seltsamen Fehler aufgespürt habe, bei dem unordered_map :: insert () die von Ihnen eingefügte Variable zerstört. Dieses höchst nicht offensichtliche Verhalten tritt nur bei neueren Compilern auf: Ich fand, dass Clang 3.2-3.4 und GCC 4.8 die einzigen Compiler sind, die diese "Funktion" demonstrieren.

Hier ist ein reduzierter Code aus meiner Hauptcodebasis, der das Problem demonstriert:

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

Ich würde, wie wahrscheinlich die meisten C ++ - Programmierer, erwarten, dass die Ausgabe ungefähr so ​​aussieht:

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

Aber mit Clang 3.2-3.4 und GCC 4.8 bekomme ich stattdessen Folgendes:

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

Was möglicherweise keinen Sinn ergibt , bis Sie die Dokumente auf unordered_map :: insert () unter http://www.cplusplus.com/reference/unordered_map/unordered_map/insert/ genau untersuchen, wobei Überladung Nr. 2 lautet:

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

Dies ist eine gierige universelle Referenzverschiebungsüberladung, die alles verbraucht, was nicht mit einer der anderen Überladungen übereinstimmt, und die Konstruktion in einen value_type verschiebt. Warum hat unser Code oben diese Überladung gewählt und nicht die Überladung unordered_map :: value_type, wie es wahrscheinlich die meisten erwarten würden?

Die Antwort starrt Sie ins Gesicht: unordered_map :: value_type ist ein Paar < const int, std :: shared_ptr> und der Compiler würde richtig denken, dass ein Paar < int , std :: shared_ptr> nicht konvertierbar ist. Daher wählt der Compiler die universelle Referenzüberladung für Verschiebungen, die das Original zerstört, obwohl der Programmierer nicht std :: move () verwendet. Dies ist die typische Konvention, um anzuzeigen, dass Sie mit der Zerstörung einer Variablen einverstanden sind. Daher ist das Verhalten zur Zerstörung von Einfügungen gemäß dem C ++ 11-Standard tatsächlich korrekt , und ältere Compiler waren falsch .

Sie können jetzt wahrscheinlich sehen, warum ich drei Tage gebraucht habe, um diesen Fehler zu diagnostizieren. In einer großen Codebasis, in der der in unordered_map eingefügte Typ ein im Quellcode weit entfernt definierter Typedef war, war dies überhaupt nicht offensichtlich, und es kam niemandem in den Sinn, zu überprüfen, ob der Typedef mit value_type identisch war.

Also meine Fragen an Stack Overflow:

1. Warum zerstören ältere Compiler keine Variablen, die wie neuere Compiler eingefügt wurden? Ich meine, sogar GCC 4.7 macht das nicht und es entspricht ziemlich den Standards.

2. Ist dieses Problem allgemein bekannt, weil das Aktualisieren von Compilern dazu führt, dass Code, der früher funktionierte, plötzlich nicht mehr funktioniert?

3. Hat das C ++ - Standardkomitee dieses Verhalten beabsichtigt?

4. Wie würden Sie vorschlagen, dass unordered_map :: insert () geändert wird, um ein besseres Verhalten zu erzielen? Ich frage dies, denn wenn es hier Unterstützung gibt, beabsichtige ich, dieses Verhalten als N-Hinweis an WG21 zu senden und sie zu bitten, ein besseres Verhalten zu implementieren.

Wie andere in den Kommentaren ausgeführt haben, sollte sich der "universelle" Konstruktor nicht immer von seiner Argumentation entfernen. Es soll sich bewegen, wenn das Argument wirklich ein Wert ist, und kopieren, wenn es ein Wert ist.

Das Verhalten, das Sie beobachten und das sich immer bewegt, ist ein Fehler in libstdc ++, der jetzt gemäß einem Kommentar zu der Frage behoben wird. Für die Neugierigen habe ich mir die g ++ - 4.8 Header angesehen.

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

Letzteres verwendet falsch, std::movewo es verwendet werden sollte std::forward.

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

Dies ist eine gierige universelle Referenzverschiebungsüberladung, die alles verbraucht, was nicht mit einer der anderen Überladungen übereinstimmt, und die Konstruktion in einen value_type verschiebt.

Das ist es, was manche Leute als universelle Referenz bezeichnen , aber es ist wirklich ein Zusammenbruch der Referenz . In Ihrem Fall, wenn das Argument ein l-Wert vom Typ ist pair<int,shared_ptr<int>>, führt dies nicht dazu, dass das Argument eine r-Wert-Referenz ist, und es sollte nicht von diesem verschoben werden.

Warum hat unser Code oben diese Überladung gewählt und nicht die Überladung unordered_map :: value_type, wie es wahrscheinlich die meisten erwarten würden?

Weil Sie, wie viele andere Menschen zuvor, das value_typeim Container falsch interpretiert haben . Das value_typevon *map(ob bestellt oder ungeordnet) ist pair<const K, T>, was in Ihrem Fall ist pair<const int, shared_ptr<int>>. Der nicht übereinstimmende Typ beseitigt die erwartete Überlastung:

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