为什么 map::operator[] 在设计上很慢

Why is map::operator[] slow by design?

本文关键字：map operator 为什么      更新时间：2023-10-16

问题：

Peope对此抱怨：在 STL 映射中，使用 map：：insert 比使用 [] 更好吗？

访问时 

std::map<Key, ExpensiveDefaultConstructorValue> data;
data[key1] // <-- Calls default constructor each time it is called, 
           // even when the element is there

实现简单而优雅，但完全效率低下（好吧，取自unordered_map）。

_Tp& operator[](const key_type& __key)
   { return _M_ht.find_or_insert(value_type(__key, _Tp())).second; }

显而易见的解决方案

_Tp& operator[](const key_type& __key)
   { return _M_ht.find_or_insert_default(key_type(__key)).second; }

find_or_insert_default仅在需要时调用_Tp()（即元素不存在）

为什么不呢？

在知道您需要新元素之前构建新元素时，这种悲观的方法是否可能导致其他问题？

这是标准库，他们应该竭尽全力优化它。为什么不使用这种简单的方法？

至少

从 g++ 4.5 开始，std::map就没有这样的问题了：

// stripped comments and requirements
mapped_type&
operator[](const key_type& __k)
{    
    iterator __i = lower_bound(__k);
    if (__i == end() || key_comp()(__k, (*__i).first))
        __i = insert(__i, value_type(__k, mapped_type()));
    return (*__i).second;
}

您发布的代码段不是来自std::map，而是来自 hash_map ，这是该库的 GCC 扩展：

00052 /** @file backward/hash_map
00053  *  This file is a GNU extension to the Standard C++ Library (possibly
00054  *  containing extensions from the HP/SGI STL subset).
00055  */

由于它是一个扩展，维护者实际上没有义务遵循任何复杂性/性能规则（即使你提出的功能会更快）。请注意，hash_map已被 std::unordered_map 的实现所取代，如果元素存在，则不使用构造函数。

相关文章：