Saltar a contenido

Última actualización：2026-10-12

Análisis del código fuente de STL unordered_map

0.Introducción

Antes hemos estudiado hashtable, y esta sección trata de su adaptador de contenedor: unordered_map.

Por tanto, el contenedor subyacente del map no ordenado es hashtable.

El código fuente de unordered_map y unordered_multimap está en el fichero unordered_map.h.

1.Diferencia esencial entre unordered_map y unordered_multimap

Veamos primero el código fuente de unordered_map:

template<class _Key, class _Tp,
class _Hash = hash<_Key>,
class _Pred = std::equal_to<_Key>,
class _Alloc = std::allocator<std::pair<const _Key, _Tp> > >
class unordered_map
{
    typedef __umap_hashtable<_Key, _Tp, _Hash, _Pred, _Alloc>  _Hashtable;
    _Hashtable _M_h;
};

Vamos a la declaración del __umap_hashtable del contenedor subyacente:

template<bool _Cache>
using __umap_traits = __detail::_Hashtable_traits<_Cache, false, true>;

template<typename _Key,
    typename _Tp,
    typename _Hash = hash<_Key>,
    typename _Pred = std::equal_to<_Key>,
    typename _Alloc = std::allocator<std::pair<const _Key, _Tp> >,
    typename _Tr = __umap_traits<__cache_default<_Key, _Hash>::value>>
using __umap_hashtable = _Hashtable<_Key, std::pair<const _Key, _Tp>,
_Alloc, __detail::_Select1st,
_Pred, _Hash,
__detail::_Mod_range_hashing,
__detail::_Default_ranged_hash,
__detail::_Prime_rehash_policy, _Tr>;

Podemos extraer la conclusión siguiente: parámetros de plantilla de hashtable: 

template<typename _Key, typename _Value, typename _Alloc,
typename _ExtractKey, typename _Equal,
typename _H1, typename _H2, typename _Hash,
typename _RehashPolicy, typename _Traits>
Por defecto, unordered_map usa: - H1 es hash - H2 es _Mod_range_hashing - _Hash es _Default_ranged_hash - _RehashPolicy es _Prime_rehash_policy - _Traits es _Tr El último, _Tr, es muy importante, porque precisamente gracias a este parámetro existe unordered_multimap. El análisis concreto, a continuación:

_Tr es lo siguiente:

typename _Tr = __umap_traits<__cache_default<_Key, _Hash>::value>>

_Tr usa __umap_traits; seguimos mirando: 

template<bool _Cache>
using __umap_traits = __detail::_Hashtable_traits<_Cache, false, true>;
Comparando los dos anteriores se descubre que dentro de __umap_traits hay un __cache_default; veámoslo. El parámetro de plantilla es de tipo bool, así que se puede imprimir si es false o true; tras probarlo, es false, lo que significa que no se cachea el hash code.

template<typename _Tp, typename _Hash>
using __cache_default
=  __not_<__and_<__is_fast_hash<_Hash>,
__detail::__is_noexcept_hash<_Tp, _Hash>>>;
Seguimos con __umap_traits, que en realidad invoca _Hashtable_traits; seguimos hacia abajo:

template<bool _Cache_hash_code, bool _Constant_iterators, bool _Unique_keys>
struct _Hashtable_traits
{
    using __hash_cached = __bool_constant<_Cache_hash_code>;
    using __constant_iterators = __bool_constant<_Constant_iterators>;
    using __unique_keys = __bool_constant<_Unique_keys>;
};
Se ven tres using, que pueden entenderse como tres typedef que indican, en orden: si se cachea o no el hash code, si los iteradores son constantes y si la key es única; y mirando hacia atrás arriba, lo que se pasa dentro son tres parámetros de plantilla, false,false,true, lo que confirma también que unordered_map tiene keys únicas; el unordered_multimap correspondiente sería el de keys no únicas, con el último parámetro a false. Encontramos el código correspondiente:

/// Base types for unordered_multimap.
template<bool _Cache>
using __ummap_traits = __detail::_Hashtable_traits<_Cache, false, false>;

En resumen, con el análisis anterior conocemos la diferencia esencial entre unordered_map y unordered_multimap y descubrimos cómo implementar dos adaptadores de contenedor sobre un mismo contenedor en el código fuente subyacente.

2.Diferencia esencial entre unordered_set y unordered_multiset

El análisis es igual que el anterior; primero, unordered_set:

template<class _Value,
    class _Hash = hash<_Value>,
    class _Pred = std::equal_to<_Value>,
    class _Alloc = std::allocator<_Value> >
class unordered_set
{
    typedef __uset_hashtable<_Value, _Hash, _Pred, _Alloc>  _Hashtable;
    _Hashtable _M_h;
}

template<bool _Cache>
using __uset_traits = __detail::_Hashtable_traits<_Cache, true, true>;

template<typename _Value,
    typename _Hash = hash<_Value>,
    typename _Pred = std::equal_to<_Value>,
    typename _Alloc = std::allocator<_Value>,
    typename _Tr = __uset_traits<__cache_default<_Value, _Hash>::value>>
using __uset_hashtable = _Hashtable<_Value, _Value, _Alloc,
                __detail::_Identity, _Pred, _Hash,
                __detail::_Mod_range_hashing,
                __detail::_Default_ranged_hash,
                __detail::_Prime_rehash_policy, _Tr>;
Se ve que lo que se pasa a _Hashtable_traits es false,true,true. Para unordered_set se usan const iterator y key única; veamos ahora unordered_multiset:

template<bool _Cache>
using __umset_traits = __detail::_Hashtable_traits<_Cache, true, false>;
Comparando ambos, lo esencial es que unordered_set no permite keys repetidas, mientras que unordered_multiset sí las permite.

3.Tres grandes conclusiones

Ahora, con la base anterior, enumeramos los cuatro adaptadores de contenedor:

(1) unordered_map 

template<bool _Cache>
using __umap_traits = __detail::_Hashtable_traits<_Cache, false, true>;
(2) unordered_multimap 
template<bool _Cache>
using __umap_traits = __detail::_Hashtable_traits<_Cache, false, false>;
(3) unordered_set

template<bool _Cache>
using __uset_traits = __detail::_Hashtable_traits<_Cache, true, true>;
(4) unordered_multiset

template<bool _Cache>
using __uset_traits = __detail::_Hashtable_traits<_Cache, true, false>;

Tras compararlos, concluimos

  • Conclusión 1: unordered_map y unordered_set no permiten keys repetidas, mientras que las variantes con multi sí las permiten;
  • Conclusión 2: unordered_map y unordered_multimap usan el iterador iterator, mientras que unordered_set y unordered_multiset usan const_iterator.
  • Conclusión 3: en unordered_map y unordered_multimap la key es key y el value es key+value; en cambio, en unordered_set y unordered_multiset la key es el Value y el Value también es la Key.

La última conclusión se ve comparando lo siguiente (mirad el primer y el segundo parámetro que se pasan a hashtable):

unordered_map y unordered_multimap: 

using __umap_hashtable = _Hashtable<_Key, 
std::pair<const _Key, _Tp>,
_Alloc, __detail::_Select1st,
_Pred, _Hash,
__detail::_Mod_range_hashing,
__detail::_Default_ranged_hash,
__detail::_Prime_rehash_policy, _Tr>;
unordered_set y unordered_multiset: 
template<typename _Value,
typename _Hash = hash<_Value>,
typename _Pred = std::equal_to<_Value>,
typename _Alloc = std::allocator<_Value>,
typename _Tr = __uset_traits<__cache_default<_Value, _Hash>::value>>
using __uset_hashtable = _Hashtable<_Value, _Value, _Alloc,
__detail::_Identity, _Pred, _Hash,
__detail::_Mod_range_hashing,
__detail::_Default_ranged_hash,
__detail::_Prime_rehash_policy, _Tr>;

4.Funciones importantes de unordered_map

Inicialización

En el constructor siguiente se puede ver que el número de cubos por defecto de unordered_map es 10.

En la capa inferior, unordered_map usa por defecto hasher(), es decir H1, es decir std::hash

unordered_map(size_type __n = 10,
    const hasher& __hf = hasher(),
    const key_equal& __eql = key_equal(),
    const allocator_type& __a = allocator_type())
: _M_h(__n, __hf, __eql, __a)
{ }
A continuación probamos si se usa el hash por defecto:

unordered_map<string,int> um;
hash<string> h;
cout<<um.hash_function()("hhhhhawq")<<endl;
cout<<h("hhhhhawq")<<endl;
Salida:

9074142923776869151
9074142923776869151
Lo que verifica aún más el uso del hash por defecto.

¿Vacío, tamaño, tamaño máximo?

bool
empty() const noexcept
{ return _M_h.empty(); }
///  Returns the size of the %unordered_map.
size_type
size() const noexcept
{ return _M_h.size(); }

///  Returns the maximum size of the %unordered_map.
size_type
max_size() const noexcept
{ return _M_h.max_size(); }

begin y end

iterator
begin() noexcept
{ return _M_h.begin(); }
iterator
end() noexcept
{ return _M_h.end(); }

insert Cinco formas de inserción

// value
std::pair<iterator, bool>
insert(const value_type& __x)
{ return _M_h.insert(__x); }

// pair 
std::pair<iterator, bool>
insert(_Pair&& __x)
{ return _M_h.insert(std::forward<_Pair>(__x)); }

// iterator+value
iterator
insert(const_iterator __hint, const value_type& __x)
{ return _M_h.insert(__hint, __x); }


// first到last范围插入
template<typename _InputIterator>
void
insert(_InputIterator __first, _InputIterator __last)
{ _M_h.insert(__first, __last); }

// 初始化列表插入

void
insert(initializer_list<value_type> __l)
{ _M_h.insert(__l); }

Borrado

Tres formas de borrado

// iterator
iterator
erase(iterator __position)
{ return _M_h.erase(__position); }

// key
size_type
erase(const key_type& __x)
{ return _M_h.erase(__x); }

// first到last范围

iterator
erase(const_iterator __first, const_iterator __last)
{ return _M_h.erase(__first, __last);

Limpieza

void
clear() noexcept
{ _M_h.clear(); }

hash_function

Obtener la hash_function de ese unordered_map 

hasher
hash_function() const
{ return _M_h.hash_function(); }
Uso: 
unordered_map<string,int> um;
cout<<um.hash_function()("hhhhhawq")<<endl; //传递的内容要与上面key类型一致。

key_eq key_eq devuelve std::equal_to Se usa así: 

unordered_map<string,int> um;
cout<<um.key_eq()("1","2")<<endl;
Búsqueda y obtención del value

iterator
find(const key_type& __x)
{ return _M_h.find(__x); }
mapped_type&
operator[](const key_type& __k)
{ return _M_h[__k]; }
mapped_type&
at(const key_type& __k)
{ return _M_h.at(__k); }
Además de estas funciones, hay otras para obtener los cubos, el número máximo de cubos, el factor de carga, rehash, etc.; lo que no hay es ordenación, porque hashtable no ofrece funcionalidad de ordenación. En hashtable, buscar, borrar e insertar nodos cuesta tiempo constante, mejor que el árbol rojo-negro RB-Tree.

Análogamente, unordered_set, unordered_multiset y unordered_multimap tienen las mismas funciones que unordered_map, así que no las detallo.

Temas relacionados

Comentarios