Come specializzare std :: hash <Key> :: operator () per il tipo definito dall'utente in contenitori non ordinati?

Per supportare i tipi di chiave definiti dall'utente in std::unordered_set<Key>e std::unordered_map<Key, Value> si deve fornire operator==(Key, Key)un hash funtore:

struct X { int id; /* ... */ };
bool operator==(X a, X b) { return a.id == b.id; }

struct MyHash {
  size_t operator()(const X& x) const { return std::hash<int>()(x.id); }
};

std::unordered_set<X, MyHash> s;

Sarebbe più conveniente scrivere solo std::unordered_set<X> con un hash predefinito per il tipo X, come per i tipi forniti con il compilatore e la libreria. Dopo aver consultato

• C ++ Standard Draft N3242 §20.8.12 [unord.hash] e §17.6.3.4 [hash.requirements],
• Boost.Unordered
• g ++ include\c++\4.7.0\bits\functional_hash.h
• VC10 include\xfunctional
• varie domande correlate in Stack Overflow

sembra possibile specializzarsi std::hash<X>::operator():

namespace std { // argh!
  template <>
  inline size_t 
  hash<X>::operator()(const X& x) const { return hash<int>()(x.id); } // works for MS VC10, but not for g++
  // or
  // hash<X>::operator()(X x) const { return hash<int>()(x.id); }     // works for g++ 4.7, but not for VC10 
}                                                                             

Dato che il supporto del compilatore per C ++ 11 è ancora sperimentale --- non ho provato Clang ---, queste sono le mie domande:

1. È legale aggiungere una tale specializzazione allo spazio dei nomi std? Ho sentimenti contrastanti al riguardo.

2. Quale delle std::hash<X>::operator()versioni, se esiste, è conforme allo standard C ++ 11?

3. C'è un modo portatile per farlo?

Sei espressamente autorizzato e incoraggiato ad aggiungere specializzazioni allo spazio dei nomi std*. Il modo corretto (e fondamentalmente unico) per aggiungere una funzione hash è questo:

namespace std {
  template <> struct hash<Foo>
  {
    size_t operator()(const Foo & x) const
    {
      /* your code here, e.g. "return hash<int>()(x.value);" */
    }
  };
}

(Altre specializzazioni popolari che potresti considerare di supportare sono std::less, std::equal_toe std::swap.)

_{*) fintanto che uno dei tipi coinvolti è definito dall'utente, suppongo.}

La mia scommessa sarebbe sull'argomento del modello Hash per le classi unordered_map / unorder_set / ...:

#include <unordered_set>
#include <functional>

struct X 
{
    int x, y;
    std::size_t gethash() const { return (x*39)^y; }
};

typedef std::unordered_set<X, std::size_t(*)(const X&)> Xunset;
typedef std::unordered_set<X, std::function<std::size_t(const X&)> > Xunset2;

int main()
{
    auto hashX = [](const X&x) { return x.gethash(); };

    Xunset  my_set (0, hashX);
    Xunset2 my_set2(0, hashX); // if you prefer a more flexible set typedef
}

Ovviamente

• hashX potrebbe anche essere una funzione statica globale
• nel secondo caso, potresti passarlo
  • l'oggetto funtore vecchio stile ( struct Xhasher { size_t operator(const X&) const; };)
  • std::hash<X>()
  • qualsiasi espressione vincolante che soddisfi la firma -

@Kerrek SB ha coperto 1) e 3).

2) Anche se g ++ e VC10 si dichiarano std::hash<T>::operator()con firme diverse, entrambe le implementazioni della libreria sono conformi allo Standard.

Lo Standard non specifica i membri di std::hash<T>. Dice solo che ciascuna di queste specializzazioni deve soddisfare gli stessi requisiti "hash" necessari per il secondo argomento del modello std::unordered_sete così via. Vale a dire:

• Il tipo hash Hè un oggetto funzione, con almeno un tipo di argomento Key.
• H è una copia costruibile.
• H è distruttibile.
• Se hè un'espressione di tipo Ho const H, ed kè un'espressione di un tipo convertibile in (possibilmente const) Key, allora h(k)è un'espressione valida con tipo size_t.
• Se hè un'espressione di tipo Ho const H, ed uè un valore di tipo Key, allora h(u)è un'espressione valida con tipo size_tche non modifica u.